Our friends and neighbors at the new Eucalyptus Systems just got funding from no less than Benchmark and BV Capital. That’s a pretty exceptional accomplishment in the current venture climate! Read more about it at Venture beat or on the new Eucalyptus site directly. Oh, in case you missed my recent posts, Eucalyptus is open source software that lets you set-up your own cloud in you own datacenter. You can then plug your Eucalyptus cloud into RightScale and manage it through the RightScale dashboard alongside all the public clouds. Go Eucalyptus!
Archive for April, 2009
RightScale + Ubuntu + Eucalyptus = cloud in a box
Need a cloud in a box? Want a cloud in a box? Well, then, start requisitioning a couple of machines now so you’re ready on Thursday to load up Ubuntu 9.04, install Eucalyptus, and follow the prompt to register your cloud with RightScale! And best of all, it’s all free! Free open source software and access to a free RightScale service account.
It’s been a hectic last few months and I’m sure we have some interesting times ahead, but we’re finally getting oh so close with the impending release of Ubuntu 9.04 which includes the technology preview for the Ubuntu Enterprise Cloud powered by Eucalyptus. We’ve been working very closely with both Canonical and the Eucalyptus team to ensure that all the cloud pieces will work together as seamlessly as possible.
To make it easy for you to set up your private cloud we integrated the RightScale registration into the Eucalyptus installation. This means that as you plod along installing and configuring your Eucalyptus cloud controller you’ll have the option to register your new cloud with RightScale by simply following a link on the configuration web page. It could hardly be any simpler.
What we’re supporting at the Ubuntu 9.04 release is to register your Eucalyptus cloud with RightScale and access it within your RightScale free or paid account right alongside Amazon EC2. You can invite friends to access your cloud so they can launch their own cloud servers on your cloud! We will also provide a RightImage that you can download to your cloud so you have a clean and small machine image to work with. Unfortunately, we won’t have support for ServerTemplates and automation available at the initial release. We still have a number of things to hook up on our end to make that happen, but we’ll release it as soon as it’s ready. At that point, you’ll be able to operate in your own cloud just as you do on EC2. Yikes!
But we’re by no means forgetting about Amazon EC2! We’ve been working with Canonical to ensure that the official Ubuntu 9.04 Amazon Machine Images (AMIs) work out of the box with RightScale! This means that if you launch one of the 9.04 AMIs from the RightScale dashboard then all the RightScale goodness will work: server templates, monitoring, automation, etc. If you launch the same AMI using the API or from a different console, then they’ll work as if RightScale didn’t exist. The inclusion of the RightScale start-up script in the Ubuntu AMI means that we’ll be able to continue ramping up our Ubuntu support and we won’t have to create a 9.04 image ourselves at this point. In the future, as we roll out new versions of our configuration management and automation we’ll probably release new Ubuntu RightImages ourselves, but we’ll cross that bridge when the time comes. In the meantime, enjoy Ubuntu 9.04 & RightScale seamlessly on Amazon EC2!
My cloud, your cloud, our cloud
As we’re getting ready to support private and hybrid clouds in RightScale I thought it would be worthwhile to write up some of the experience and thinking that we’ve gone through. Over the past few months we’ve seen a sustained rise in the buzz around private and hybrid clouds. As far as I’m aware, the following terminology has pretty much emerged from multiple sources:
- a public cloud is a shared cloud computing infrastructure that anyone can access and that is connected to the public Internet
- a private cloud is a cloud computing infrastructure owned by a single party (usually with deep pockets to pay for datacenters and machines!) and that may or may not be connected to the public Internet
- a hybrid cloud is the union of private and public clouds that are used together to be able to leverage the benefits of both
To date cloud computing has by and large been in the realm of public clouds. There has been a lot of buzz around “I want a cloud in my own datacenter” but it is taking time for the technology to mature and for players to commit the resources and do the build-out. Let’s review the pros of public vs. private clouds (pros of one are cons of the other):
Public clouds:
- no capital expenditures — pay per use
- ability to pass headaches of expansion to someone else
- no physical plant staff and reduced sysadmin staff
- leverage high-volume Internet connectivity
Private clouds:
- ability to control details of hardware provisioning and of hardware characteristics
- fully owned infrastructure reduces security concerns, ability to satisfy regulatory requirements without requiring cooperation of cloud provider
- close proximity to non-cloud datacenter resources, potentially also to offices or other parts of physical plant
- may leverage existing resources (sunk costs)
What has been really interesting to watch is the level of interest in hybrid clouds, which is an attempt to get the best of both worlds. While many organizations would really love to have a private cloud they realize that a lot of what attracts them to the cloud computing model in the first place is intrinsic to the public cloud. So it is natural to want to put into the public cloud the workloads that benefit from its advantages and into the private cloud what is better served there.
From the bullet lists above it is clear that the benefits of the public cloud all revolve around cost and can only be duplicated internally at a really large scale. The benefits of the private cloud all revolve around control. So it makes sense that almost everyone ends up gravitating toward wanting a hybrid model.
I was originally skeptical about the whole notion of an internal cloud. What ended up convincing me is the long list of use cases we’ve encountered. Here are the most typical ones:
Develop in public, deploy in private. You may be outsourcing part of the development and so running dev and test servers in the public cloud makes it all much easier. Even if the developers are internal but distributed around the globe it’s often easier to converge in the public cloud. The flexibility to acquire and relinquish dev as well as test resources is also often a key benefit. But in the end production may have to run internally for regulatory reasons or similar concerns. In that case it should ideally run in an internal cloud that is managed the same way that dev & test resources were to ensure that everything works as planned.
Develop in private, deploy in public. You may have existing in-house dev and test resources that you’d like to bring to bear on projects that ultimately will be launched in the public cloud for connectivity, redundancy, and scalability reasons. Being able to test using the same type of environment as will be used in production is a good reason to set up an internal cloud with the same management system bridging the internal and external deployments.
Private core, public expansion. You may have applications in-house that need to stay there for regulatory or other reasons but you have related apps that can run internally or externally. For example, batch analysis, seasonal/temporary apps, etc. These can run internally or be moved to the public cloud and having the flexibility can ease the transition as well as help optimize costs.
Some runs are public, some are private, some are in-between. You may have researchers running modeling or analysis applications that span the spectrum of security requirements. Some runs or experiments use public software and run on public domain data sets, these are likely able to run in the public cloud already. Others use proprietary software and operate on very secret data sets. Some of these may never be candidates for the public cloud. Many other experiments fall in-between. Giving the researchers the ability to launch a cluster of machines on-demand internally or externally whenever they want to test something out can really enhance productivity and reduce overall cost.
What we hear across the board is the requirement to link the two types of clouds together. Users want to be able to seamlessly move applications back and forth. Oops, let me be more precise. Users want the assurance that they can develop an application and build deployments in one cloud in such a way that they can replicate the same type of deployment successfully in the other type of cloud. And they would like to use the same management system for all these deployments. It’s basically the requirement of being able to realize the above use cases.
What we fortunately hear much less frequently are ideas about seamlessly scaling apps out from the private cloud into the public cloud. Sort of transparently adding public cloud resources to your private cloud when the latter runs out of capacity on one app. The reason I’m not a fan of this is that it just raises a lot of tricky technical issues, from latency and bandwidth bottlenecks to routing and access control issues.
I believe there is a very simple realization that makes such “scale out into the public cloud” scenarios unattractive: by the time you convinced yourself that you can run half of an app in the public cloud, you effectively also convinced yourself that you could run it entirely in the public cloud! I’ll come to exceptions below, but what happens is that the most cost effective way to proceed is to move the app entirely into the public cloud and make room in your datacenter for the growth requirements of some other app that is more difficult to run in the public cloud.
Good exceptions are situations where your application has legacy requirements around the database tier but you want to run some compute intensive parts of the application in the public cloud. Say you have an Oracle RAC installation that you can’t move into the public cloud, but you need an increasing amount of horsepower to perform compute intensive analysis of some data. Then it’s interesting to evaluate how the database can stay in private and the compute stuff can scale out into the public cloud.
Next week we’ll take the first step in supporting the above use cases by allowing anyone to plug their private cloud into the RightScale service! For free! We’ll help you do the following:
- commandeer a bunch of machines
- create a cloud using Eucalyptus
- register your cloud with RightScale
- enjoy the power of RightScale for your cloud for free
- invite your friends to your cloud
All this will be just the first step on a long road towards realizing the promise of hybrid cloud architectures, stay tuned for more!
McKinsey doesn’t ‘get’ the cloud…
It looks like the McKinsey report “Clearing the air on cloud computing” is getting some attention. It has some good stuff in it, including the warning that cloud computing is approaching the top of the Gartner hype cycle. However, its claim that cloud computing (in the guise of EC2) ends up being more expensive per server month for large enterprises than doing it in-house seems fatally flawed. In particular, it doesn’t seem to be accounting for the costs correctly and it completely fails overlook the benefits of automation in the cloud which ultimately leads to a revolution in the way compute resources are consumed.
The cost equation in the report starts on slide 22 and it’s really, really sketchy. They mix EC2 compute units and cores together (compare 22 and 23). They talk about “$14K/Server (2 CPU, 4 core)” which on my calculator comes out to $97/core/month over 3 years, but they have a cost of $45/mo/cpu on the same slide (and $97 doesn’t even account for the facility or power or cooling).
On slide 24 they suddenly compare an in-house datacenter server with “75% of EC2 Large Standard Windows configuration on Amazon EC2″ and nowhere do they mention that the latter cost includes the Windows license. Ouch!
Unless they actually document more details of their cost accounting I can only say that it’s flawed. This is supported by the many business line owners in large corporations that come to us and tell us they can’t believe how cheap EC2 is because their internal charge-backs by IT are $400+ per server.
The other big mystery is how McKinsey arrives at just a 10% labor reduction when moving to a “third-party cloud provider” and they quote $96/mo of labor for the cloud servers. For what? For the guy that clicks the “launch” and “terminate” buttons on the management dashboard???
Again, the report is so thin on details that it’s impossible to figure out what they’re really thinking. Clearly there is a lot of staff required to run a whole datacenter as well as a lot of service providers, from the architects and engineers to build the facility, to the hvac guys cleaning filters, the folks maintaining the UPS batteries, the genset, and the security crew. 10%, yeah, right.
What the report seems to completely overlook is the possible reduction in sysadmin costs. One of the huge benefits of the cloud is that the entire computing infrastructure can be automated. Top to bottom. That saves a lot of sysadmin labor and in the end it means that requisitioning more compute capacity can be done by the end user somewhere in a business unit instead of being an IT chore.
The report also doesn’t take into account the cost of the red tape that surrounds corporate IT. Things the business can’t do because IT can’t support them. Wasted time spent doing work-arounds instead of just launching a few more servers. Having to guess 6 months ahead of time how many servers will be needed at launch. Opportunity cost because projects don’t happen for lack of IT resources.
Well, I have to say that it would have been great to read a report that lays out the costs and assumptions clearly so one can retrace what is included and what is not. I would have loved to learn more about the corp IT costs. Alas the report fails to do that and it also fails to recognize that cloud computing revolutionizes the way compute resources are consumed, which ultimately is where the bigger benefits will come from.
