Multicloud is the concept of consuming resources from differing public and/or private cloud providers to deliver your computing needs. There now many public clouds, including Azure, AWS, GCP, and OVH, which operate at a global level, while others, including Interoute in Europe, Alibaba in China, and Dimension Data in Australia, have a regional footprint. Specialist government cloud providers like FedRAMP and G-Cloud provide a digital marketplace for governmental agencies to procure and consume cloud resources. This sounds like Nirvana.

MultiCloud PuppetMaster
MultiCloud PuppetMaster

However, the fact is that multicloud is difficult both as a concept and to deliver. Azure, AWS, GCP, and OVH all have differing provisioning processes, differing services, and differing methods of presenting the same services. Ingestion into these providers is easy, but extraction and movement at the infrastructure layer is not; in some cases, the providers actively place blockers to deter movement.

Cloud-native applications and containers could possibly be the answer, abstracting the operating system and hypervisor out of the stack. However, the vast majority of consumers are just not ready for this leap. Their applications are too legacy. If you feel skeptical, remember that IBM still makes significant revenue from its zSeries mainframes and CICS software product, which are entering their sixth decade of service.

Multicloud will be easier when the application stack is container driven, or serverless. Currently this is led by Lambda from AWS. While the push for it is championed by many vendors, that day is not today. Today, we are still infrastructure driven, shackled by hypervisor virtualization differences.

Why would you want a multicloud strategy?

There are many reasons; a few are outlined below:

  • Cost: Cloud provider A may be cheaper for archival storage, while Cloud B offers better computer costs at load.
  • Resilience: There are not enough regions in your country. We have spoken at length about this here.
  • Risk mitigation: By spreading your compute requirements across differing providers, you avoid putting all your eggs in one basket.

Of course, unless you manage to spread your servers across similar hypervisor stacks from an IaaS perspective, server mobility is not an option. Even the process of deploying your compute stack is fraught with difficulties.

How can we bring calm to this chaos?

Paraphrasing Tolkien, we need a ring to rule all other rings. These questions are starting to be answered. VMware has its cross-cloud initiative. It isn’t really a multicloud manager, but an attempt to place vSphere at the heart of everyone’s cloud (I am looking at VMware on AWS here). This will not help with managing your Azure, GCP, or even traditional AWS cloud deployments.

This is where a multicloud-aware product comes into focus. A significant amount of work is being done in this arena. Companies like RightScale and HashiCorp are front and center in the fight to tame the multicloud beast, with common orchestration and delivery platforms, placement based on policy rules, and the ability to deploy on differing hypervisor platforms. Seamless movement of workloads is still quite a way off, but this is more of a “would like” than a “really need.” More and more resilience logic is being programmed in at the application level moving forward. However, this kind of multicloud-aware product is the future, not today.

Today, with the correct tools, companies can orchestrate their cloud to deploy across multiple public or private cloud locations based on various rules sets, if they have a common deployment definition methodology, be that Terraform in the case of HashiCorp or Kubernetes, or your deployment tool of choice. However, there are still significant gaps in the functionality that is needed to be fully pan-cloud capable. Things are improving, but it is unlikely that there will be a single ring to rule all needs. At least the openness of RESTful APIs allows development of key functionality without having to continually reinvent the wheel, seat, and door handle.

What should you look for in a cloud provider if you are considering a multicloud strategy?

When you look at Azure, GCP, and AWS, you are confronted by a dazzling array of services and possible options. What are the key callouts you should be looking at? RESTful APIs, or at the very least a fully functional published and supported SDK; support for common deployment methodologies (Kubernetes, Terraform, PowerShell/Python support); and the ability to monitor your environment from a common platform (Nagios, SolarWinds, etc.)

One of the main reasons for a multicloud deployment is cost minimization. The ability to set rules to automatically and dynamically stretch and contract your compute across multiple platforms relies on the ability to speak a common language. This is a new and emerging market, and there are others that have yet to break cover with some very interesting offerings in this space. We are not in Nirvana today, but the journey has started. It is incumbent upon CIOs, CTOs, and other strategists to start looking at this.