momius - Fotolia
Putting together a hybrid configuration of your own in-house servers and one (or more) public clouds is a challenge. It's not simply a case of taking your virtualized server farm and adding a piece of code that extends everything into your public cloud of choice. There are potential problems with data movement, security questions and the whole issue of mapping applications to the hybrid cloud architecture.
Determine your application needs
For many enterprises, application mapping is a good place to start. What do you really want to place in a public cloud, and what do you insist must be kept in-house? A formal study might surprise you; A good deal of data is public domain. All those browsed Web pages and most of the data on company public websites could be on the public side. This would allow scaling where necessary, and cope with the diurnal load patterns.
By far and away the most interesting, and the most important part of a hybrid cloud architecture is applications that straddle the hybrid-public boundary and take advantage of "cloud bursting." Cloud bursting is a term used to describe adding a load of public VMs to an app running in private VMs when demand peaks. Cloud bursting requires rapid movement of data and savvy optimization techniques.
With an application map in hand, traffic patterns for the various applications over time and a first pass at cloud bursting, the next step is to look at the logistics of what should be where. Getting data into the public cloud is typically inexpensive or even free. That's because cloud service providers want to store as much as possible -- and then bill you for it later. Taking data out of the cloud costs money, using fees based on quantity per month.
Latency and data movement
In the world of microsecond latencies, public clouds are on another continent. Transfers will take considerably more time than an in-house LAN. This creates a potential synchronization problem for files, and especially relational databases, where the application may not be designed for the very long delays needed to propagate locks and releases.
The data access time question is going to change all those plans. A good rule of thumb is to take compute to where the data is (and not the other way around). Look for static or slow-changing data such as customer lists and preferred component tables that get updated rarely, and plan to copy these into the public cloud, while making sure that there is a batch update process. This sort of replication is easy to manage.
Data security in the cloud
Volatile data is a more complex issue, but let's first consider the security of a hybrid cloud architecture. Most CIOs still regard the cloud as porous and insecure, but the reality is that the opposite is true. Public clouds are generally more secure than customers' premises, for the simple reason that any effort on security spent by a cloud service provider is leveraged across hundreds of thousands of similar servers. That leverage of scale allows providers to spend more on security than even a large enterprise can afford.
Data covered by HIPAA and SOX needs careful handling. That doesn't mean data must be in-house, it means that data access must be restricted and the data protected from third parties. Many companies -- in an abundance of caution -- keep that data unnecessarily close. What really matters for HIPAA and compliance requirements is the question of control. Who can access your data? Sensitive data moved to the cloud has to be encrypted, and not by using the service provider's encryption service. This means both data at rest and data in transit. However, that's the standard you should be following for in-house storage, and if you are, you have a way to encrypt and decrypt on each server. Encrypted data can migrate, so once you have mapped the applications participating in cloud bursting, the major task is making data available to the public cloud side from the private side.
Mostly, this involves the creation of standby copies of data in public cloud storage and mechanisms for keeping files synced. There are some tricks to consider here. A multiple provider health cooperative might organize files by provider, and keep some completely on in-house storage and the others on public cloud storage. This company would realize most of the benefits of cloud bursting by moving a few provider data sets and associated programming back and forth across the boundary.
Another trick is to look for those low-volatility common files that can be replicated in both places. Looking at transactional systems, the only data needing immediate transfer is often just inventory levels, which have to be synced to prevent overselling. The rest of the data in a transaction can be delayed.
Of course, there are situations where all of this falls down. Cloud bursting high-performance computing applications could lead to very large files needing to be moved. With today's slow, expensive WAN connections, this is a big issue. A number of companies are addressing fixes that might help. One approach is to host the storage within telecommunications facilities so it can be accessed through dedicated very fast fibre links to the cloud service provider. This solves the public cloud issue, and incidentally adds a security blanket (pun intended) to IT operations that think HIPAA means "in-house."
One logical consequence of the ever-improving security of public clouds and the data logistics issues is that it's very likely more apps will be moved totally to the public cloud. This may make the hybrid cloud a stepping-stone for enterprises that will eventually end up entirely in the public cloud, but most organizations are conservative and risk-averse so this process may take a while.
Do the benefits of hybrid cloud live up to the hype?
Guiding the way to a hybrid cloud deployment
Is a hybrid cloud architecture just a stepping stone or the end goal?