Hybrid and Multi-Cloud Environments: What You Need To Know
Beyond management applications there are more practical concerns that need to be borne in mind when thinking about engaging in hybrid and multi-cloud IT deployments.
So you've solved how to get your workloads into the cloud without getting sued. But now you have workloads in a managed cloud and on your own on-premises datacenter. You might even be looking at using multiple public clouds. How best to go about this?
The answer is that there is no good answer. The solution that we all want doesn't seem to exist. In a perfect world, there would be multiple hybrid multi-cloud management vendors all offering fully independent management capabilities, unified Role Based Access Control (RBAC), as well as inter-cloud workload migration, cost control, backup and disaster recovery. Ideally, they'd also do security and best practice audits against all infrastructures under management, and offer up rich reporting and monitoring, as well.
While there exists a number of solutions that try to accomplish this task, they all fall down in one way or another. Putting to one side that it's difficult to find even one provider that can meet the feature list, infrastructure diversity support is sorely lacking among the extant multi-cloud management vendors.
Every independent multi-cloud management vendor appears to support the two biggest public clouds: Amazon Web Services (AWS) and Microsoft Azure. Most support the third-largest public cloud, the Google Cloud Platform, with a smaller number of vendors supporting the fourth-largest public cloud, the IBM Cloud.
If IBM has trouble getting love, you can imagine what support for smaller cloud providers looks like. Many of the multi-cloud management solutions have hand-waving-class support for OpenStack, but when you drill down into it, they don't have much of a partner ecosystem actually signed up behind that supposed support.
VMware Cloud on AWS makes the occasional showing, but this makes sense, given that VMware is dumping incomprehensible resources into promoting VMware Cloud on AWS. Support for the much more vibrant -- and arguably important -- vCloud Director (vCD) services provider ecosystem is virtually nonexistent, as is support for CloudStack-based providers.
Yes, No, Maybe, Could You Repeat the Question?
Some solutions come close. Cisco CloudCenter appears to support vCD when deployed on-premises, but does not seem to support it from services providers. Morpheus added vCD support in version 3.1.0, though this isn't discussed anywhere on its main Web page, leaving room for questions about just how solid support really is.
In fact, the Web sites of the various multi-cloud management vendors are almost universally awful. Scalr, for example, has a pretty graphic that seems to indicate support for Azure, OpenStack, VMware, GCP and AWS. But VMware what? vCenter on-premises? VMware cloud on AWS? vCD ecosystem services providers? That information doesn't seem to be posted anywhere. (The Sclar Twitter team confirmed that it "has native support for VMware via vSphere [not via vCloud Director].")
The DevOps community has a few more options here. Infrastructure automation overachiever Terraform offers a number of providers, including vCD. And while it is possible to assemble every single multi-cloud management feature discussed here using tools common to the DevOps crowd, you'll end up needing a lot of tools to get the job done.
Naming, shaming and praising vendors in this space could be its own book. The relevant takeaway is that if your journey into the hybrid multi-cloud is predicated on finding a single pane of glass that solves all of your multi-cloud woes, then as of March 2018, you're chasing unicorns.
The net result of this is that in order to successfully do hybrid multi-cloud anything you have one of two paths: take a scripting-heavy DevOps approach, or know ahead of time exactly which infrastructure providers you wish to use, and ask every multi-cloud management application vendor you can find about support for your preferred infrastructure providers.
Beyond management applications there are more practical concerns that need to be borne in mind when thinking about engaging in hybrid and multi-cloud IT deployments. Chief among these are data protection concerns, data lifecycle management and networking.
Cloud workloads need data protection, just like on-premises ones. Achieving this data protection can be tricky. Relying on cloud provider snapshots doesn't provide any more real-world protection than relying on nothing more than snapshots from your on-premises virtualization infrastructure.
Of more equivocal value is the ability of some cloud providers to offer data protection by copying snapshots to a datacenter in another region. There's validity in this form of data protection: The data is in two places, and those two locations are geographically distinct. Unfortunately, the data is not on two different physical mediums, and all data is controlled by a single entity (the cloud provider in question).
A better solution would be to use cloud-to-cloud data protection to back workloads up from one cloud provider to another. In this way, those workloads are resilient not merely against the failure of individual infrastructure components or loss of a datacenter. They're resiliency issues that affect the entire cloud provider.
Moving data and workloads from cloud to cloud is something that should not be taken lightly, however. Many cloud providers -- big and small alike -- charge far more to remove data from their cloud than they do to put data into that cloud.
These data charges should be a serious consideration when considering cloud data protection, cloud migration, or having workloads located in multiple clouds operate on the same dataset. Not all cloud providers have this restriction. In this case, it's often best to run production workloads on providers that won't break the bank on outbound data, and back those workloads up to a different cloud provider.
Similarly, it's increasingly common practice to run your cloud data storage from a central third-party services provider with flexible network pricing. These services providers often have high throughput connections to the big four public cloud providers, as well as many of the other large services providers.
If the latency is low enough, workloads can operate in on one public cloud, but store data in another. This is useful in cases where the same dataset needs to be operated on by workloads in multiple public clouds, but where exporting that data from one cloud and then importing it into another isn't economical.
An example of why your organization might do this is if it wanted to use the Bulk Data Computational Analysis (BDCA) tools from multiple public cloud providers. BDCA solutions tend to be proprietary to each cloud provider, meaning that an organization must make the data available to each in turn in order to use them all.
Interconnecting infrastructures rely on networking -- whether those are on-premises, in a major public cloud provider, or a regional services provider. Software-defined networking (SDN) such as VMware NSX is increasingly taking the place of traditional VPNs as the ideal solution to stretch and seamlessly connect these infrastructures.
The key buzzword to keep in mind is layer 2 extensibility. In traditional networking each infrastructure would have its own subnets. A workload with the IP address 10.0.0.100 on one infrastructure might not be able to use that same IP on another infrastructure. This can cause a lot of problems for non-composable workloads.
SDN that incorporates layer 2 extensibility can solve this. The networking of all participating infrastructures can essentially be joined into one unified network. While not absolutely required for hybrid or multi-cloud computing, it makes everything much simpler. Especially when disaster recovery enters the mix.
Both hybrid and multi-cloud computing are entirely possible today. Things remain a little rough around the edges, but the requisite bits are there. As always, working directly with services providers makes all of this much easier. It will be several years yet before the multi-cloud management solutions remove the need to work with other humans to smooth out the kinks.
Trevor Pott is a full-time nerd from Edmonton, Alberta, Canada. He splits his time between systems administration, technology writing, and consulting. As a consultant he helps Silicon Valley startups better understand systems administrators and how to sell to them.