Making the Case for Hybrid Cloud

IDC’s CloudView Survey from last year included respondents that spanned a wide variety of both IT and line of business users. Overwhelmingly, they placed a great deal of importance on using a hybrid cloud strategy.

If you look carefully at the characteristics of what “hybrid cloud” even means, the most popular responses were that it meant using multiple public clouds and mixing them with dedicated assets in what can be thought of as a private cloud.

But taking on a strategy that involves multiple clouds sparks a number of questions even after the clouds themselves have been selected:

• How do you know which applications should be placed on which clouds?
• When should you revisit that placement decision and what factors should be considered when moving an application from one cloud to another or even keeping it where it is?
• How do you handle the complexity of managing and scaling a multi-cloud system?
• What’s the balance between that complexity and cloud portability for individual applications?

Initial Placement: Not Just About Price

Once clouds for a multi-cloud strategy have been selected, one of the first things an organization must grapple with is figuring out which applications in the portfolio should be hosted on which cloud initially. Price is the typical factor that leads any decision criteria for initial placement, but it should hardly be the only one. Some other factors that warrant consideration include:

• Data Sensitivity – Some applications, like public-facing marketing websites, contain data that carries no risk should it become compromised. These are therefore great fits for public clouds. Others, like financial planning tools, might benefit from a physical corporate firewall in a private data center.
• Location – Certain applications benefit from being closer to their constituents so that network latency can be reduced. With the wide variety of public cloud locations available across multiple vendors, it can sometimes be wise to place value on where an application sits given its audience.
• Demand – Some applications generate traffic that varies wildly and are therefore great fits for public clouds, while others have steady workload demand that is often cheaper to meet with a private data center.
• Corporate Relationship – This often rears itself in the form of better pricing or support, but some organizations have pre-existing corporate relationships with either public cloud parents or providers of private cloud components that might shape a placement decision.
• Performance – Do not assume that all applications run the same in different clouds. Any placement decision should include performance benchmarking on possible landing spots.

Reassessing: How Often, What and Migrations

Once initially placed, the one thing that is certain is that circumstances will change. Public cloud providers constantly open new locations or offer different pricing or instance sizes. Private cloud cost factors change as new equipment is purchased. Business optimizations change as different business units alter their strategies, typically becoming more cost- and security-sensitive over time.

Generally speaking, all applications should reassess by way of performance testing annually. If you used a Cloud Management Platform (CMP) to do the initial testing and placement, this should be easy. Simply re-execute the performance testing on the different cloud candidates and see if anything has changed that would warrant a migration from one cloud to another based on a combination of price and performance.

However, market or business circumstances might dictate a reassessment more frequently than that. For example, if two public clouds get in a pricing war, or a new location opens that happens to be closer to your constituents for a certain application, a reevaluation would be in order. Keeping informed on the state of the market is crucial to determining when an on-demand assessment makes sense in addition to the annually scheduled one.

Migrations

Once you make the decision to move an application from one cloud to another—keeping in mind that the best choice might be to leave the application where it is—a CMP can help. Typically, a CMP will characterize the deployment of an application in some repeatable way, making the redeployment of that same application at a different cloud location very simple. Migrating data can be a little trickier, but most CMPs provide a mechanism for backing up data on the current cloud and restoring it to the new location.

Without a CMP, a migration can be laborious. Typically, a set of automations is written to install the application on a specific cloud when performing the initial deployment in absence of a CMP. To do so requires a certain level of expertise on that cloud, which is then lost when a second cloud is chosen to host the same application later.

Utilizing the CMP, however, typically requires less effort than learning the APIs for a specific cloud and abstracts the details away from the application architect in such a way that it becomes trivial to redeploy the application elsewhere later.

Moving Forward

As we’ve seen from the IDC study, most organizations are not going “all in” on one cloud, but instead spreading bets across many both public and private clouds. Determining which applications go where initially is highly—but not exclusively—dependent upon price. Other factors are important as well. Each application should have its hosting location reassessed once a year. Performing the initial placement assessment as well as the ongoing ones can be eased by using a CMP, which can also be helpful when performing migrations when market and business factures deem them necessary.

About the Author

A 20+ year tech industry veteran, Pete Johnson is the Technical Solutions Architect for Cloud in the Global Partner Organization at Cisco Systems Inc. He can be found on Twitter at @nerdguru