What do we mean by Hybrid Cloud?

The answer is?—?as with a lot of things?—?it depends!

Here are a couple of examples…

On-premise and Cloud

Customers with a large pre-existing on-premise deployment are unlikely to junk it all and move to the Cloud in one quick move. However, they may wish to move some low-end servers or services (what VMware have referred to in the past as ‘low-hanging fruit’) and move on from there. Over time, they may set up an Exchange DAG member or an SQL Availability Group cluster node with their Cloud provider, and if failover tests prove successful, they may choose to make the move permanent. Over time more and more services are moved to their Cloud provider, particularly if on-premise capex is a factor.

Multiple Cloud providers, using layer-3 routing and automatic DNS failover

The idea behind these designs came from several painful experiences had by some of our technical team at previous employers. These companies had chosen to stretch networks between datacenters at layer-2, so that servers and network services could easily be stretched between sites on the same VLAN and subnet. This might work well for a small, or single-customer solution, but when scaled to a service-provider network spanning four or five datacenters it quickly became a bad idea. Imagine a broadcast storm rippling out to multiple sites which are all one gigantic layer-2 broadcast domain, and you can imagine some of the troubleshooting issues encountered by the technical teams.

Instead?—?a more scalable solution is to architect service provider networks and larger customer solutions as layer-3. A customer solution might consist of multiple ‘pods’?—?including a separate public IP range, firewall & loadbalancer clusters, web and database servers?—?per site. A DNS solution such as Dyn can be used to automatically fail over an A record should the primary stop responding, or carry out geolocation-based load-balancing.

Now?—?imagine you have architected your application to suit a layer-3 routed solution with a single service provider. Perhaps there is a private link between the sites, or perhaps there are VPN tunnels between the firewall clusters. At this point, it is not much more work to split the pods between different service providers, increasing resilience.

Leveraging particular features of particular Cloud providers

A customer might choose to host their services on the Cloudhelix vCloud platform. However, they might also have a requirement to send their backups to a 3rd party archiving service, such as Amazon Glacier. They might even have their own Amazon VPC to use as part of a highly-available solution design. For this reason we are happy to offer services using a private interconnect (Amazon Direct Connect).

If a customer has a requirement for a private interconnect to a different provider?—?perhaps Microsoft Azure ExpressRoute?—?we are happy to consider this.

Summary

If nothing else, this post has demonstrated that there are a lot of ways to say ‘it depends’! It should also demonstrate that, while VMware’s vCloud Hybrid Service (vCHS) is an exciting new development, there are many other kinds of hybrid cloud to consider.