The advantages of public cloud are well-known: self-serve API-oriented resources and large scale allow enormous elasticity and agility. Compute and storage resources can be spun up and down quickly in response to changing needs, whether they be load pikes or simply the convenience of not paying for development machines on weekends. Public cloud resources are available across the world, making it easier to run applications where they are needed, and expand businesses quickly to new markets. And certain technologies, because of their scale and elasticity are particularly suited to public cloud: big data and machine learning being among obvious examples.

But not everything is appropriate for public cloud. Some hardware or applications may simply be unavailable in public cloud, or in the geo-region necessary. Regulation or corporate policy restrict what can be run outside of a region or data-center. Or latency requirements may force applications to be closer to customers, to plant or devices, or to databases or hardware that cannot be moved for other reasons. Sometimes it is just easier and less expensive to keep using existing hardware where it is (if it ain’t broke, don’t fix it).

The hybrid cloud model is where a scenario involves code and applications running in a hyperscale public cloud like Microsoft Azure and a traditional data center or co-location facility. We see many common patterns for hybrid cloud. Dev and test are often done in public cloud before final deployment to a private data-center. As mentioned above, the requirements for developer and test machines are often uneven: reduced in the evenings and over weekends, spiking when certain types of tests are running. Because development is usually not done against production, the security, compliance and latency needs may not be as severe making easier to use public cloud without upsetting the security team or auditors.

In talking with customers, partners, analysts and my colleagues in Azure, I find that the range of hybrid scenarios is so wide that it becomes confusing. The requirements for one hybrid scenario are so different from another, that we end up talking about different things. It helps to break hybrid down into some patterns and categories.

Here I will not enumerate all the hybrid cloud patterns, but rather point out that all of them seem to fall into two broad categories, which are often conflated. In the first category, the same code is running in both the public cloud and the local datacenter. In the second category, different code is running in the two different places. These categories I call symmetric and asymmetric.

Dev/test, cloud bursting, and failover for availability are examples of symmetric hybrid patterns: the same code must be running in both places to enable these scenarios. Most people I talk to think first of symmetric patterns when discussing hybrid cloud.

Asymmetric scenarios are by usually more complex, though cloud backup is a common simple use case. Another easily understood example is where for compliance or hardware reasons, production data must stay in a local datacenter, but can be appropriately queried from a cloud-hosted web interface. IoT edge scenarios are often extreme examples of asymmetric hybrids.  If all the devices are talking directly to public cloud, that’s a very asymmetric edge scenario because the devices don’t resemble the cloud services at all. But often it makes sense for devices to talk to field gateways and local datacenters, where aggregation and filtering is done before cloud-appropriate data is sent to the public cloud for further analytics and longer-term storage. These field gateways start to look more like cloud servers, and in cases like with Azure Stack may be very close…falling into the symmetric cloud category.

Of course, some scenarios have symmetric and asymmetric elements, with some code being the same in both places, and some different. It is also true that even if the same production code is running in two places, the control plane APIs may be different (also true of multi-cloud), so that symmetric usage patterns may have asymmetric operations.

Describing every hybrid pattern is beyond the scope of this blog post. In fact, many hybrid patterns are unknown and still being developed, especially asymmetric hybrids. Here I simply want to introduce this terminology, because we have found it useful and clarifying in our discussions with customers and among ourselves to differentiate.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s