It's been a long held belief that one should never put all their eggs into a single basket. To not back a single horse. In the enterprise space, many, if not most customers have followed this tried and true methodology as they dip their toes into the digital transformation that is "the cloud." Having spent the past decade working with large companies that spent millions a year as well as small companies spending only a few hundred dollars a month on cloud, I was a principle architect of that pattern. It came from a sense of pragmatism, but also provided an excellent hedge for organizations to back "the number two cloud" but without too much risk.
I was wrong.
Fundamentally, we have seen a myth emerge that backing multiple horses in the cloud wars was a great way to achieve leverage to reduce costs, attain multi-discipline capabilities in the quest for greater agility and protect against the headwinds that the early 2010s were bringing with such technical disruption. These myths all chased after a singular pipe dream: by backing more than one horse, we are safer from obsolescence. What we've seen, however, is the exact opposite. Let's begin with the why's.
Governance is Hard
The ability to prevent cloud sprawl is an often repeated concern of cloud adopters. Organizations are under tremendous pressure to digitally transform. They are under equally enormous pressure to be more agile and to adopt the pattern flavor of the month "devops." But the increasing complexity of cloud deployment models (now easily on par with the behemoths of data center management of our previous generations) have led to herculean efforts to managing a standard, compliant and consistent architecture within an organization. In order to continue transforming into that agile "devops" and "infrastructure as code" patterns, cloud providers have continued to develop and offer numerous SKUs, best practices and patterns that must be closely followed to keep things manageable. Indeed, my cloud has delivered a number of SKUs that specifically target management, governance, security, audit-ability, etc - and our customers are getting REALLY good at it.
Now imagine doing all of that in more than one place. Imagine an organization willingly committing "blood and treasure" to supporting at an enterprise grade the above critical pieces of your digital transformation. It very much takes on a war zone like feel when you talk to the poor souls on the front line. Governance of a true multi-cloud architecture in a large enterprise is not just insanely difficult, it is impossible.
Why Do We Govern?
We govern because we must. A company cannot transform itself and risk the entire portfolio of its business assets. There are several key strategic reasons for governance that we break down:
- Strategic "Direction"
- Cost Containment
- Technical Decision Criteria
- Data Governance (ex-filtration, DLP, partner/supplier requirements)
I submit to you that one cannot govern / control a cloud in the enterprise on any of the above priorities.
From a strategic direction perspective, it can make a great deal of sense to back multiple horses. "No vendor lock in," they promise. The fallacy here is that if you don't back a horse, you will lose ALL vendor safety valves the very moment you go beyond the 'least common denominator' of cloud services: storage, network, compute. To some in the C Suite, we hear that this is a good thing! "We'll be vendor agnostic and move workloads between any cloud we choose." No. You. Won't - and if you try, you'll lose time, money and, tragically, data. My advice? Back a horse and become a partner to that provider, not merely a customer. Trust me, we're looking for a few good TRUE partners to not only help you digitally transform, but help us digitally transform with you.
The naysayer will say, "oh, we're just gonna use containers for everything and then we'll truly be agile and cloud agnostic." No. You. Won't. All cloud providers offer a common denominator of compute, storage and networking - this we've discussed. But you cannot possibly take into account all of the nuances of each cloud's specific implementation of containerization technology or governance any more than you could have a common storage endpoint for all clouds or a common networking model for all clouds or a common....and if you try, kernel panics and failed PODs will happen. I've seen it, I've hugged the engineers that have tried it. And if, by some miracle you DO succeed in a cross cloud containerization approach, you are now truly and completely stuck because you won't be able to touch a single value service outside of that orchestration engine - that's right, no PaaS, no SaaS - you may as well have been running a bunch of VMs.
"We shall save money by leveraging our relationships and pit one cloud against another for optimal pricing concessions." "We shall govern our clouds so as to contain costs and realize on demand resource allocation regardless of cloud platform by leveraging a common set of Infrastructure as Code tooling." No. You. Won't. Despite all the hype and impressive services offered by third party orchestration systems, they all fail to help you with a fundamental flaw - no cloud is built equally. You may find a great solution to "see" your costs, but at scale, you will not be able to control them without enormous burden to your IT staff, automation delays in processing and you STILL haven't been able to convince me that it is worse architecting to the least common denominator. And this notion of leveraging relationships for cost concessions? I've got a secret for you - unless you exist here, the economics of cloud does not afford the kind of negotiating leverage you once thought were possible in the traditional on premise models. And even if you do exist "there," a given cloud provider may promise you the moon, but where the rubber hits the road is where it matters - you can get a sweetheart deal and it can still be a terrible business decision. Why? Because until it breaks, you are swimming the easy lane. It's when it breaks (us or you) when you find out the true total cost of cloud ownership. Did you ring every last penny out of the contract such that now no one will be there to take your call? Or did you pay a fair market value and get a partnership level commitment to your success? Cost containment as a zero sum game is a dangerous game to play with your corporate assets.
Technical Decision Criteria
Each cloud has value. Each cloud has merit. Each cloud has an 'edge' on the other guy that may last a year, or, in many cases, a few months. Digital transformation doesn't move at YOUR speed. It moves at market speed, and the market moves way faster than you can hold technical review board meetings. I've helped cloud adoption teams in multiple organizations as they learn to develop their transformation muscle and they assume that just because you can choose the better widget from X and the better widget from Y at any given point in time doth not make it a good idea. Where is the VALUE in saying "we're gonna use AWS for all our microservices and Azure for all our DBs and Google for all our Big Data and Oracle cause reasons." The technical decision criteria cannot JUST be the right tool for the right job at the right time - it has to ALSO be the right tool we can support at the right time. The cloud is not a buffet of services you get to pick and choose from and pit one versus the other. This is the same tried and failed methodology of yesteryear when CIOs set edicts that said "I shall only buy the tech that's in the top right corner of the Magic Quadrant." Look at what that got those CIOs - an unholy integration nightmare. It remains true today. You must choose your cloud based not just on the overall strategy you are developing, but also the strategy of the cloud provider. Do you know what the strategy of your provider is? If not, you are just a customer - not a partner. Does SQL Azure outperform AWS? Yep. Does AWS S3 storage kick Azure's butt? Yep. So how do you decide without choosing *.leader? You choose not JUST on technical decision criteria, you choose based on the relationship, the price, and yes, the pace of change in the cloud (which can be a good thing!).
"Data and compute for this system will live in that cloud and data and compute for that system will live in that other cloud." These decisions get made based on the above constraints but lack a fundamental awareness that with each new cloud you attempt to onboard and govern, you exponentially increase your risk for a data breach, failure of governance or, at worst, business ending error. I've had three customers in the past six month justify their multi-cloud solution governance concerns by stating: "that's a networking problem and to solve that problem, we're going to force tunnel all network traffic between all clouds back to on premise." No. You. Aren't. In no cloud is it a good idea to force tunnel all traffic back on premise. For starters, ewe, but more specifically, it immediately eliminates major components and valuable services from said cloud because forced tunneling is a red herring and they don't support it. It is a legacy construct to assume you can govern your data through networking alone. Next, you will expend most of your budget on data egress charges. Then, you'll have a very (nay, impossible) time in developing a coherent DR/BC strategy. And finally, in order to realize the value of cloud services, you have to cede control of the packets to a higher power and rely on better data governance tools that were invented in this century. Only just now are data governance tools that can protect data assets across multiple clouds being invented. You truly need to invest and know where each cloud places data security value. You need to understand if you are a customer of the cloud provider or a partner.
Whether it is training costs, unintended opex, compliance litigation, network egress charges, or just sheer unfathomable complexity, a true enterprise cloud cannot be multi-cloud. I've been in the field now for a long time and witnessed the pain and suffering of too many organizations attempting to do so. We see organizations large and small that initially deployed into a multi-cloud strategy now calling us back in to help them lick their wounds. Are you a customer or a partner? I know for a fact that from an enterprise perspective, there is a cloud provider that is literally incented to become your partner, not just make you our customer. You can have great pricing, data security, governance and agility. But back a single horse. And choose wisely.