Tuesday, October 9, 2012

Hybrid Cloud: Public to Private

Prior to joining Eucalyptus I heard a lot of hype around Hybrid Cloud - the combination of on premise and public clouds. Most of the time someone would talk about how businesses were going to run applications behind the firewall (private cloud) and "burst" to the public cloud when demand exceeded thresholds. What I soon discovered was that "cloud bursting" was closer to hype. On the other hand, there were real hybrid cloud use cases that were delivering real value to customers.

This is the first in a series of blog posts in which I explore hybrid cloud scenarios. We'll begin with the model that many organizations started with over the past 5 years - using Public then Private clouds.

Why Start with Public Clouds

An application begins its life cycle within the public cloud for any number of reasons. If you look back 4 or more years ago, there wasn't much in the way of private clouds so we can skip the obvious "there is no private cloud" reason. These days there tend to be two common reasons developers adopt public clouds; it's faster and it's cheaper. Let's consider those in turn.

It's Faster

To clarify, I'm not suggesting public cloud resources are inherently better performing. Rather, it's faster to start developing in the public cloud because a Dev can swipe a credit card and get compute / storage and networking resources in a couple minutes or less. By contrast, many development teams cite having to wait days or even weeks to get a working environment stood up. With private cloud software such as Eucalyptus gaining traction in the enterprise, the days (or rather weeks) of legacy provisioning times are soon to be over.

It's Cheaper

The second reason public cloud is a good starting point is that it can be cheaper than on-premise resources for certain types of use cases. I'm thinking specifically of a gaming company that wants to launch a new game. They do not yet know how popular the game will be and couldn't simply guess at how many resources to acquire / provision. Just imagine buying 1000 machines to host a new game only to find out it's a flop. Or having only 10 machines, but losing potential customers because game performance is terrible. The public cloud allows you to dynamically size your application based on demand and at a reasonable cost.

One could easily point to many other reasons why  development teams adopted public cloud. Regardless of the reasons there's no denying that the public cloud continues to provide significant benefit. What I find more interesting is that companies are now actively evaluating private cloud options and, in the case of Eucalyptus customers, deriving real value. Even more interesting is that they aren't abandoning the private cloud but instead are using the model to improve business agility, address regulatory requirements and taking control over cloud SLAs.

Moving Public to Private

For this post I am considering the cases in which a customer started development in the public cloud, and now wants to bring the application back behind the firewall. The first thing to said about such as move is that one does not simply redeploy the application on premise. In fact many companies found out the hard way that applications designed and developed for the cloud aren't easily moved to standard on premise hardware or basic virtualized environments. Check out Steve Bradshaw's excellent points on significant differences between cloud and virtualization.

The good news for companies today is that enterprise-grade, on premise cloud computing is a reality. This means that development and IT teams can focus on rapidly building, testing and deploying applications without struggling with with underlying infrastructure.

So you may ask, "If my application runs in the public cloud, why do I need to bring it in-house?" Here again the answer depends entirely on specific business scenario. A couple reasons I have heard from our customer base include:

Performance Control

The public cloud is built upon commodity servers and uses shared network and storage pools. For the vast majority of applications the public cloud performs well enough. There are other applications, however, that require a certain performance level that cannot be guaranteed. One great thing about the private cloud is the level of control an organization can have. With private clouds the company can select the hardware that is most apt to give the highest performance. They can control the available compute speeds by selecting powerful processors. They can control the storage speed by using high RPM spindles, advanced SAN devices and optimized storage controllers. A company can select network equipment that scales in terms of traffic and connections. In short, the business can tweak the overall performance of the private cloud in ways that are impossible in today's public cloud environment. And as an added bonus, this can all be done without any changes to application code.

Regulation and Security Business

Applications frequently use or have access to private and confidential, or sensitive data.  In the US this data could be subject to regulation such as HIPAA for health records, or personal information covered by the Data Protection Act in the UK. Obviously a business would not run these kind of applications in the public cloud, but it isn't unusual to see app development and testing done in the public cloud (for reasons stated above cost/time). These applications must then be deployed in on premise. The benefit of using the private cloud is that the business can tightly control all access to all the resources (application, data, network, storage, compute, etc) such that data remains safe and regulations / security requirements are met.

Extend the Investment of IT Assets

Keep in mind that a private cloud is an abstraction layer above IT assets. The applications that run on the private cloud don't need to know about the physical CPU, network or spindle speeds. Deploying a private cloud gives business the added benefit of re-purposing older hardware, basically extending the life of equipment that may have otherwise aged out. Eucalyptus customers, for instance, can define an availability zone of older equipment that would suit early prototyping, long running tests or other activity that doesn't require highest performing gear. So users who were cautiously watching their public cloud budgets get burned on low priority tasks, can now move those in house and better spend the budget on key projects / applications.

Win / win.

Wrap up

I hope this post expands your definition of what Hybrid Cloud can be. Whereas it used to be synonymous with "Cloud Bursting", there are many real world scenarios driven by business needs that aren't simply about dynamically changing the application footprint. I also want to be clear that private cloud isn't a direct replacement for public cloud. They each provide their own unique benefits and, when combined, offer users the ability to deploy resources based on the economics, performance and security. In the next post we'll look at the hybrid model in which development begins in private cloud and moves to public.

1 comment:

  1. Thanks for this topic which contains an informative content regarding Hybrid Cloud which is highly informative. A Hybrid Cloud simply doesn’t exist without critical hybrid cloud services connecting the data center and the cloud.