Achieving Peak Orchestration in a Multi-Cloud Environment

Have you recently moved to the cloud? Perhaps you are mulling over your accomplishments having moved to an agile, DevOps culture. Or maybe you have moved into SaaS-based services such as cloud databases, load balancers and container clusters? Everything is moving along just fine and dandy, but then you’re required to look at a multi-cloud solution. And now you’re facing an enormous mountain to climb to make it a reality.

Why multi-cloud in the first place?

If money is the answer, what’s the question? For most companies the move to the cloud was pretty simple -- there were realistically only two choices (Azure and AWS), with most choosing AWS. When they arrived, they realized it wasn’t as cheap as it first seemed and then immediately started looking for ways to reduce cost. Other reasons to consider multi-cloud include the following:  

It’s still mostly about the money.

What’s all the fuss?

There are five areas that can make multi-cloud adoption difficult to achieve:

 1. Vendor-native languages:What most people don’t realize about cloud computing is that the exact same services are often not actually comparable. For example, the orchestration toolset: 

There are essentially three different languages to build your infrastructure. Imagine you want to run a Kubernetes cluster to host a website. Before multi-cloud you had one codebase, one deployment pipeline and one set of servers to monitor. If you want to run that website on a different Kubernetes cluster, you won’t be able to copy/paste that configuration for another cloud -- you’ll have to write it from scratch. Terraform touts itself as one of the languages that talks to all 3 major clouds, but even if you write everything in Terraform you can’t just re-point it from AWS to Azure. You have to rework the code for each cloud environment. Other tools like Spinnaker also tout the ability to reduce the complexity of multi-cloud deployments but attract massive overheads.

2. Cloud-specific features: Another serious consideration when adopting multi-cloud is all the bits of glue that hold your platform together. IT departments are truly ‘the masters of sticky plasters’ (which often go undocumented). Imagine someone has hacked together a workflow using a Lambda function to bridge a gap in the code somewhere. You’ll never know about this until the service breaks when you run it somewhere else. AWS is excellent at providing hundreds of these micro-SaaS offerings, making it very easy to stitch a platform together, but very difficult to move that platform somewhere else.

3. 3rd party services (such as monitoring): If you’re monitoring your platform, using something like DataDog, the setup and pricing is based per cloud environment. In order to have reliable reporting and alarms you’ll need to tinker with alerts and logs, etc. Multiple sets of metrics will need to be gathered from multiple places and when something goes wrong, you’ll have multiple places to look for the problem.

4. The human element: If you split yourself across multiple clouds you can’t expect existing staff to be proficient administrators. The difference between AWS/Azure/GCP (Google Cloud Platform) is not like the difference between a BMW and a Mercedes -- it’s more like the difference between a truck and a train. You wouldn’t expect to put a truck driver in a train and everything to go smoothly; staff would need to be retrained and upskilled to accommodate the multi-cloud.

5. Auditing and complexity issues:Anyone who has had to go through a GDPR, or an ISO-27001 audit will know the pains of documenting and showing systems to auditors. Now imagine doing that multiple times. Also, if you have fully redundant systems that fail over in case of outages, you’ll now need to test this on all your cloud environments.

So, is multi-cloud worth it?

In my opinion, the true load-balanced multi-cloud is probably decades away. Although a few players (like Waze) do have a multi-cloud setup, for most it remains a concept. Dropbox famously moved their storage out of AWS and into private-cloud, GitLab moved from Azure to GCP and the Pentagon recently switched from AWS to Azure.

There may be real advantages in moving smaller chunks of your platform initially though. Perhaps you have a huge data warehouse that needs to be kept for 7 years for legal requirements -- there’s no need for this to be kept next to your main production platform. Or perhaps you’re building out a new part of your platform that integrates with IoT devices. Let’s say Microsoft has an IoT library you can use off-the-shelf, and you use that to pump data to your main production platform. It’s the sensible, quick wins like this that we should all be looking for. Don’t look to run the same services in two places, but rather, complement existing services from a multitude of places.

Steven Puddephatt, Technical Architect at GlobalDots, has worked in the industry for over 14 years with a solid background of IT operations. He has migrated several businesses from traditional data centers to cloud platforms.