Achieving Peak Orchestration in a Multi-Cloud Environment

You’ve just been asked to look at a multi-cloud solution. You might put on a brave face for upper management, but deep down you know this isn’t going to be easy. You’re right.

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.

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.