My Cloud, Your Cloud, Our Cloud

You’ve reached an archived Flexera blog post that may be out of date. Please visit the blog homepage for the most current posts.

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 data centers 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 data center” 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 data center 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 data center 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.