Hybrid: It's Not Just About Cars

Making the decision to move forward with a private cloud doesn't mean you should rule out public cloud services--you can have your cake and eat it, too. The technical and business drivers that were used to decide on private cloud may not be applicable to every service and deployment model. In most cases, the greatest benefits will be found in a mixture of private and public cloud services.

Joe Onisick

July 14, 2011

4 Min Read
Network Computing logo

Making the decision to move forward with a private cloud doesn't mean you should rule out public cloud services-- you can have your cake and eat it, too. The technical and business drivers that were used to decide on private cloud may not be applicable to every service and deployment model. In most cases, the greatest benefits will be found in a mixture of private and public cloud services.

There are two ways in which public and private services can be mixed: the more commonly recognized hybrid cloud, in which the private cloud resources and public cloud resources are merged in some fashion allowing service portability between the two, and a more pick-and-choose model in which individual services are assessed for feasibility in a private or public deployment model. Both have pros and cons, and the two can always be mixed. The key is ensuring the best business value for individual services without creating an environment that's too complex to manage or monitor.

The most commonly used example of a hybrid cloud is for the purpose of "cloud bursting." Cloud bursting is the concept of running your services on a private cloud architecture during normal operations and pushing excess capacity into the public cloud during peak periods. A great example of this would be a retail store whose compute capacity is fairly moderate and static from January through November but peaks significantly during the holiday shopping season. Cloud bursting would potentially allow the store to run in-house 10 months of the year and burst into public cloud on an as-needed basis with a pay-for-use model.

The immediate advantage to the concept of bursting is that you pay for only the predictable capacity that you can plan for, and you run that capacity at very high utilization with the safety blanket of the public cloud for both expected and unexpected peaks. The reality may be slightly different. The reality of cloud bursting is that it's not as easy as it may seem, and doesn't make sense for many models. The reason is that, if you've designed an application or service to run on a public cloud and you trust your data and security on that cloud and the public cloud's availability works for you, why are you running any portion of the service in-house?

While cloud-bursting use cases may be limited, other hybrid options exist. A great example of this would be utilizing cloud storage or other resources for business continuity and disaster recovery. The cost of maintaining a second data center for business continuity purposes is out of reach for most organizations; at the same time, the cost of losing their primary data center would most likely put them out of business. For companies that have chosen a private cloud model, public cloud services can provide a lower cost on demand pay-for-use disaster recovery strategy. While the public cloud may not be an ideal primary deployment model for that organization, it may be acceptable in disaster scenarios where the alternative is bankruptcy.The second way in which to utilize both public and private resources is on a service-by-service basis. Take a large financial institution for a hypothetical example. Let's assume there were two major points that drove the institution to private cloud: regulatory worries with financial data (such as Payment Card Industry) and legacy investment in IT infrastructure. In this case, the bank has chosen to keep its core systems in-house and architect a private cloud model to deliver the services its employees and customers need.

As this hypothetical bank's core business is financial, its IT staff excels at developing and maintaining the robust and secure systems required to run the business. That being said, its staff is not particularly adept at things like building and running customer relations management (CRM) systems. Additionally, a CRM system would not fall under the same compliance rules as the financial data, and should be appropriate for public cloud deployment. In this case, using a software-as-a-service (SaaS) solution such as Salesforce.com may provide major benefits.

In this example, something like CRM can be pushed into the public cloud, removing the burden on IT to deal with systems and services that are not core to the business or their expertise. Many services can fall into this category, even in highly specialized environments. Offloading services and applications such as CRM and email can allow the IT team to focus on driving innovation and adding value to core technologies.

Neither of these methods come without challenges. Managing a set of services that lives in both a public and private cloud environment will require careful planning and coordination. In many cases, you will want to adopt tools that have visibility into both worlds, and can monitor and manage each to some extent.

Remember that cloud computing is largely about delivering services in the most cost-effective, flexible and efficient fashion available to the business. In order to properly live up to this, services and options will need to be considered on an individual basis. What applies to one deployment model, or one service, may not apply to another.

About the Author(s)

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
More Insights