Hybrid Cloud Cookbook: An Evaluation Framework

This post is part of a series of Hybrid Cloud ‘cookbook’ blogs that discuss the key concepts of building and running a true hybrid cloud environment and delivering IT-as-a-Service.

The cloud, with all the variants, is a much overused and under delivered word, especially when it comes to the world of enterprise grade hybrid clouds. With this, let me reveal a simple framework to evaluate what we are talking about when it comes to Enterprise Hybrid Cloud.

Cloud

Just implementing an IaaS / Cloud stack does not mean that you have built and are successfully running on a cloud. The simple criteria for cloud are:

• Standardized and aggregated services – you get well defined infrastructure service which includes all the needed elements (compute, storage, network, security, data protection, etc.)
• On demand self-service – you can provision and decommission services when you want by using simple portal or API
• Measured – your consumption is measured and reported
• Elastic – your consumption can go up and down

In the case of a private cloud, the elasticity can be achieved from the user perspective, but not from the company perspective. All other criteria can and should be met.

Hybrid

Hybrid cloud means that you can do both private and public. Although this is a simple concept, it is not so easy to achieve.

The catch is that implementing separate environments is not yet hybrid. This just means that you have two or more silos which are used in different ways and do not co-operate.

Key criteria for a true hybrid cloud are:

• Workloads can seamlessly be moved between the private and public cloud
• Both clouds are used and managed through a common interface and in a common way
• Same principles apply to both clouds (governance, security, etc.)

Ease of workload movement is one of the attractive promises of hybrid cloud. However, any IT person who has tried to migrate an application in a traditional data center environment knows that even trivial distinctions such as a difference in versions of layered software can jeopardize the migration. It is highly unlikely that your private and public cloud stacks are the same. In practice, every cloud is a silo and you need to go through normal application migration effort when moving it between clouds. This also holds true in the case of OpenStack.  As a result of the many user-selectable parts in OpenStack, there are rarely two identical OpenStack implementations. Thus workload movement is certainly not guaranteed.

You have a couple options for true workload movement. Your first option is that you design and code your application from the ground up to be as IaaS agnostic as possible in terms of IaaS environments. This may also include using a Cloud Foundry-type of PaaS. The second option is that you consider public clouds that have a similar architecture to your own data center infrastructure. For example, VMware vCloud Air runs any workloads that run on your own VMware infrastructure, provided that you have extended your network appropriately.

Enterprise

Enterprise here refers to the set of qualitative criteria your cloud needs to meet. Every company has their own criteria, but the following are some of the most common ones:

• Service levels – cloud meets agreed service levels (uptime, latency, and performance)
• Security – authentication, network security, etc.
• Enforced policies – approvals, data protection rules, etc.

If you have a cloud-native application, SLAs are less critical because your application has been designed and built from the ground up to work in the public cloud with latency and performance changes. The rest of the applications need stable and predictable infrastructure.

With hybrid cloud, the public part needs to be an extension of your network, as the workloads need to be able to access the same services, regardless of the cloud that they run on. This opens up a number of security aspects to consider. It is not that public clouds are always less secure, as they can have better security than your own environment, but you still need to consider and protect.

Equally important are the policies. When you set up a new database for your infrastructure, you also probably set up some sort of backup. For critical data, you ensure that there is data mirroring between sites as well. When you enable self-service, you need to enforce the same policies (in an automated and transparent fashion).