This post was written by Sander Rodenhuis and Posted on 19 november 2017

At the ‘Structure 2017’ conference in San Francisco, Microsoft Azure chief technology officer Mark Russinovich said that Avoiding Cloud Lock-In is risky too (read the article here). Of course, Mr. Russinovich is the CTO of Azure, so you may doubt his objectivity. But doesn’t he have a point? Are people who propagate a multi cloud strategy ignoring the implications and risks involved? In this post I wrote down some food for thought before you even start thinking about adopting a multi cloud strategy.

But first let’s see what Mark Russinovich said. He said: “Enterprises pursue a multi cloud strategy to help negotiate better pricing, among other reasons. But then those enterprises have to develop expertise in two clouds, as well as managing divided workloads and data and moving them between cloud providers. Also, cloud providers have different APIs and abstractions. Virtual machines can’t simply be picked up and moved from one place to another.

So what are the risks and implications regarding expertise?

If you work with AWS, you know how much time and effort goes into keeping up with all updates and enhancements. Do you read all the weekly announcements? The risk here is that keeping up with all developments (let’s lake Azure and AWS as an example) is going to cost you a large amount of time. In every case you need to deploy new functionality, you’ll need to choose which provider to use and why.

I work for a customer who uses both AWS and Azure. We really need more people because of all the business initiatives we have to support. But finding a person who has technical knowledge of both AWS and Azure seems to be impossible. Look around you. Every day lots of request for AWS or Azure engineers/consultants pass by. Every recruiter is hunting them. Of course you can also look for a partners who manage your cloud environments for you, but doing this requires other capabilities and maturity from within your organization (contracting, service level management, et cetera). This requires you to set up a demand supply governance capability.

But what about costs?

Let’s be honest, do you compare costs (create a business case) between multiple cloud providers every single time before you start using them? And what about volume discounts? Some services in AWS, such as Amazon EC2 and Amazon S3, have volume pricing tiers across certain usage dimensions that give you lower prices the more you use the service. Using compute in both AWS and Azure can prevent you from taking advantage of AWS volume pricing tiers. The same applies to Azure. If you already have an enterprise account, the cost for Azure will be lower than the public pricing (and can end up being much cheaper than using another provider).

And what about risks and implications on different APIs and abstractions?

AWS and Azure have indeed different APIs for the same services. But that’s not all. If you use (closed) platform services like AWS Simple Queue Service (SQS), CloudFront (maybe in combination with Lambda functions), CodePipeline, et cetera, or Azure App Services with Continues Deployment for example, then applications using these services will not be easy to move over. But not using these platform services will result in using IaaS services only and then you’ll have to deploy all the required platform services yourself (what in turn will result in higher complexity and management effort).

Some more thoughts

Organizations who are taking security serious have (or are going to) implemented certain amounts of security controls. Implementing those controls in 2 different clouds can be very expensive and time consuming.

So what then?
Cloud service providers offer different services, each with their own characteristics. Choose the best solution for your use case. Select one provider where you set up a Virtual Private Cloud for IaaS and use other providers for PaaS. In the case of IaaS, you are responsible for the OS and application stack, so here you will implement controls for OS integrity, logging, monitoring, et cetera.

If you really would like to be completely independent and have the ability to switch over between providers whenever you like, go and use a cloud-native platform for building and deploying applications like Pivotal Cloud Foundry. Application build with PCF can be deployed in both Azure and AWS (but also in your on-premises vSphere environment).

To conclude
I personally am not convinced that every organization needs to focus on a multi cloud strategy. Especially small to medium sized companies and local governments should choose one (hyperscale) provider and invest heavily in gaining the required knowledge to take full advantage of all the features the provider has to over.