RightScale Blog

Cloud Management Blog
Cloud Management Blog

Enterprise-Class Software Available in the Cloud with RightScale

More and more enterprise-class software vendors are making their software available in the cloud and doing it through RightScale. Over the past two weeks the IBM DB2 team made DB2 Express-C v9.7 available, SpringSource published Hyperic HQ, and CohesiveFT published VPN-Cubed, all on the RightScale platform. Publishing software to the cloud is still a somewhat mysterious activity. While almost all software runs in infrastructure cloud environments such as Amazon EC2, publishing to the cloud creates new expectations and opportunities. Over the last year, we've been adding features to our platform to help ISVs publish to the cloud and are excited that the DB2 team found it easier to get the next version out using a RightScale ServerTemplate than an Amazon AMI.

I thought it would be helpful to write down how publishing software into the cloud is different from the more traditional software delivery:

Server templates, not software packages: Users expect to point and launch, not download, install, and configure. Of course some software is meant to be embedded or adapted, but in those cases there still is the opportunity to deliver a ready-to-go sample from which the embedding or adaptation can start.

In the cloud, you can launch IBM DB2 and have it running in a couple of minutes. That makes it much easier to get going and then later to start modifying configuration details. I'm sure most users will want to change the ServerTemplate published by IBM, but few will start there. Using the ServerTemplate not only gives you a server with the software already loaded, installed, and configured, it also has all the right software versions, is set up with monitoring and alerts, has  logging prepped correctly, plus offers other goodies.

From a vendor's point of view the great opportunity of the cloud is to control the software environment from A-Z. You don’t need to have a long list of required software packages and compatible versions, you just provide it in a neatly wrapped-up ServerTemplate that automatically installs all the right components.

Free one-click trials: They don't need to be literally one click, but the cloud offers tremendous opportunities for users to try before they buy. It's so much easier to try out software if you can just spin up a server in the cloud, possibly with some live demo data already loaded. It's even better when the server is running on the vendor's dime!

From the vendor's perspective the cost is really close to just the cloud infrastructure cost. We've offered $1 of free EC2 time in our trial sign-up for years now. The $1 is good for about 10 hours of a small EC2 instance and really lets people get a first taste of RightScale. Who wouldn't pay $1 to get a prospect to try their product?

No lonely servers: Whose software is designed to run on a lonely server these days? What use is, for example, Hyperic HQ on its own? Its purpose is to monitor other servers, so you really want to embed it into multiserver deployments. CohesiveFT's VPN-Cubed product is similarly targeted to making life easier when you have lots of servers to connect back to the main office or datacenter.

Using RightScale simplifies the configuration of multiple machines because configuration inputs can be defined across many machines at once, and it's much easier for a vendor to also provide scripts that install client plugins or agents on a customer's other servers.

Pay per use: Users have come to expect more flexible billing methods in the cloud, such as pay per use. This is good and bad. The good is that it really is a requirement for enabling the scaling of resources on demand or for supporting flexible usage models. Use cases range from the famous scaling up in response to a traffic surge, to  being able to add a database slave server on a whim to test the performance impact of some schema transformations. Pay per use really makes the cloud unique and this tells me that like it or not, pay per use is here to stay. However other models will likely coexist.

From a vendor perspective pay per use introduces new challenges. On the execution end it means that vendors need to meter the usage of their customers. I'm distinguishing metering from billing; the former is about measuring the usage and producing the data that can be used to compute per-use charges, the latter is about sending the customer a bill and getting it paid. We've been adding metering support to the RightScale platform for ourselves and we're starting to make the data available to ISVs to feed into their billing.

On-site support: The servers in the cloud are very easy to access by the vendor's support engineers and users will soon start to expect such on-site support. This is a true win-win proposition because it can reduce problem resolution time and increase customer satisfaction. Of course this means that the support reps need to have the skill to actually fix something and not just to dig in the knowledgebase and send an email reply.

One of the required underpinnings to enable vendor access in a controlled manner is access control. After all, the server's user needs to be able to selectively grant access to the vendor when help is needed. What we've found is that the RightScale dashboard not only offers the ability to do just that, but it also gives the support engineer a lot of context and history information that can help getting to the bottom of the problem quickly. As an extreme case, our support guys have responded to a number of "help, our site is down and we can't reach our IT guy" calls and were able to get things back up without having prior knowledge of the site. (In case you're wondering, this is not what our standard support covers, but we also don't just leave customers fall off the cliff in a situation like that.)

Delivered as a service: "And can you run it for me?" is a question prospects ask more and more. I know for myself that many times I'd rather pay the vendor to run it and sell it to me in SaaS form than go and figure it all out myself. Of course the cloud makes this much easier than ever before because the whole provisioning planning is largely taken out of the equation. When more customers sign up the vendor can just launch more servers. A good number of our customers do just that and utilize RightScale to manage what one could call virtual appliances for their customers. At the more sophisticated end, companies such as StarCut use RightScale to provision multitenant clusters to host many small users and they then move larger users to private clusters and even set them up with their own fully managed auto scaled deployment.

Runs everywhere: The final consideration is that "publishing to the cloud" is a rather deceptive term because there isn't just one cloud. I hate to borrow the "write once, run anywhere" slogan but it really describes what vendors are looking for. It's too early in the industry to have a clear picture of what the solution should look like, but we've certainly made significant strides towards enabling multi-cloud ServerTemplates in RightScale and we'll have more coming out shortly.

To give credit where credit is due, Amazon has done a great job in preparing the runway for software vendors to make their software available in the cloud. First, the fact that EC2 is based on immutable machine images, which are not a snapshot of a server but rather a template from which new servers can be spun up really enabled the first catalog of ready-to-launch servers. Second, the pay-per-use pricing which has gotten everyone to rethink how flexible computing could be if the licensing models allowed it. Somewhat to my surprise vendors with a lot of legacy pricing, such as IBM, have jumped into this new opportunity and decided to adopt it. Third, Amazon's DevPay service, which allows vendors to add a charge on top of Amazon's hourly server fee, was the first offering that closed the metering and billing loop so vendors don't have to reinvent the wheel. All this has created a tremendound level of awareness and interest in the new ways software can be delivered in the cloud. We're now leveraging this to introduce what we belive to be a more multi-cloud-friendly and more flexible way to publish software in the cloud.

Comments

[...] from: Enterprise-class Software becoming available in the Cloud through … Share and [...]
Glad to see you have changed your previous opinion of metering in the cloud since we last met at the CloudCamp WHD conference. But I am curious at what level can you honestly offer useful metering information if you are still largely devoid of software execution context with the processes themselves. It would be great if instead you offered RightScales metering data available within the process itself (bindings to different languages) and per thread to enable fine grain activity analysis which can be correlated to multiple cost centers some operational others more business like (chargebacks to depts, users, services, components, workflows). A bit like this example: http://williamlouth.wordpress.com/2009/01/27/abc-for-cloud-computing/ But if not that then at least we could have this today. Is this possible? http://williamlouth.wordpress.com/2009/04/18/cloud-modeling-with-activity-based-costing/
Posted by williamlouth (not verified)   Ι   July 13, 2009   Ι   10:56 AM
William, thanks for the feedback, always appreciated. We have to start somewhere and there is a lot of interest in metering that is essentially at the granularity of servers (plus or minus ancillary resources used by each server). You are talking about finer granularity where, for example, a multi-tenant system could associate detailed costs with each tenant. I guess we can have a religious debate over the point of diminishing returns in such schemes, but in the end I don't think this is an area where we'd be adding a lot of value. Your product is much more versatile in that area, for example. What we do plan to offer, however, is a way to feed custom metering increments into whatever we do. But one step at a time...
Response by Tim (not verified)   Ι   August 05, 2009   Ι   04:48 AM
Thorsten Leave it at the server, that's much better than for the physical world and plenty for most enterprise app biz cases for cloud migration to be compelling. I don't really understand how you're going to do finer grained metering anyway: if I've got an Oracle DBMS running DBs that are shared between business applications, how do I know which resource request relates to which user of which biz application? This is an interesting approach, but it requires a greenfield deployment to work (ie start from scratch with your business applications), which is a lot of capex to lay out for most enterprises. Depends on where you see your markets, I suppose. Threads don't scale in a parallel world anyway...
"to feed custom metering increments into whatever we do" That would be interesting as our technology does indeed allow cloud platform vendors to publish their meters within the application runtime and for changes in such meters to be correlated with application activity which to be honest would be needed if you was to apply any cost control in the cloud especially if one if offering a cloud service which is metered at the interaction point and has varying workload patterns depending on the context associated with the interaction. Metering (at least the way we have defined it and approach the problem) can encompass much more including application performance monitoring, capacity planning, cost management, user monitoring/profiling, and billing (to some degree). Why would we want to have separate models for each of these domains when all that is different is the meter (or meters) used to manage from a particular perspective. We can have many different meters each offering different levels of abstraction suitable to the domain but all based on the same activity catalog included in the metering model. Server metrics (alone) do not instigate change (in terms of cost and behavior) unless one understand the cause (activity) and effect (resource usage).
Posted by williamlouth (not verified)   Ι   July 13, 2009   Ι   11:22 PM
We took a look at your webinar and wrote a bit about your services over on our blog. A discussion is starting that would benefit from your perspectives. I had the chance to meet a few of your team members at CloudCamp Portland. Dean Dierickx served as a knowledgeable source about use cases for various deployment models. A number of dicussions we'd like to follow up on that you write about in this post. In particular, the issues around metering.

Post a comment