Dan Scarfe with an alternative look at the trend for hybrid and multi-cloud architectures – does the world really need to be this complex?
“The key to success in any enterprise-wide, large scale technology transformation programme is to make sure that our environment is as complex as we can possibly make it, through the use of as many incompatible products and services as we can possibly find.”
Said no one. Ever. Yet this is exactly what organisations are doing every day. They don’t use words like complex or incompatible. Instead, they use words like hybrid and multi; but be under no illusion, they are one and the same. What does it even mean?
Let’s start by examining the words hybrid and multi. They have subtly different meanings, but the essence is the same: choice. Hybrid typically refers to the use of two different models of IT delivery, perhaps an on-premise private cloud alongside a hyperscaler. Multi-cloud typically refers to the use of more than one hyperscaler, but can also mean on-premise and public cloud together. The pitch is that you get to use the best model at the right time for less money. It sounds great, but the true meaning is all very – and deliberately – murky and confusing.
Why are we even talking about it?
To understand the importance of hybrid and multi-cloud, it’s useful to understand some of the players and motivations here. One of the single greatest reasons to adopt public cloud technologies is to simplify your IT environment. Much of what you used to have to worry about is now taken care of for you. No need to worry about servers or switches or any of those oh-so-dull things of yesteryear. Unfortunately, someone’s job or someone’s services contract relies on exactly all that work we used to have to do. Simplicity, in the eyes of some, can be a scourge.
And here’s what happened. Choosing a primary provider and the simplicity which it would result in, is simply redefined to mean something quite different. It’s defined to mean constraint and two words that would send a shiver down any executive’s back. Lock-in.
To allay the oh-so-easily fanned flames of fear uncertainty and doubt (FUD), the architects came up with the perfect solution. Abstraction. No longer would we rely on the services delivered by one of these providers, instead we would either buy or build our own abstraction platform across the clouds. Both VMware and IBM have bet their entire businesses on this model and story. Kubernetes is often dropped into conversation like it’s some miracle cure for all the complexity of the past three decades. Some magic tonic which will solve all of the world’s ills. Tanzu and OpenShift are VMware and IBM’s Kubernetes platforms, respectively.
I had an interesting meeting once with a rep from one of these two companies talking about their respective product. The pitch was amazing. No more lock-in. Freedom to move workloads at will with no concern about the underlying environment. If I didn’t understand this stuff I might even have been fooled. After they finished their pitch, I said to them:
“You’ve spent a lot of time telling me how important it is to avoid being locked into a vendor. How important it is to be able to move your information between providers. By buying into your platform, am I not simply moving my ‘lock-in’ to you instead?” There was a pause. “Well, it’s not really like that” was the short version of the reply I got back. I thanked them for their time and showed them out.
Is lock-in really such a terrible thing?
As we examine the case for hybrid and multi-cloud, the same topic keeps coming up again and again: lock-in. It’s impossible not to find someone in the IT industry without a harrowing story about how vendor x or vendor y did something quite horrific to them. Magic terms in agreements. Miscommunication. Configuration errors. You name it. The answer is always the same. A large bill. Microsoft was chief protagonist. An entire industry of software asset management was born to actively encourage this combative relationship between customers and vendors. Pistols at dawn one day towards the end of Q4. These executives vowed, never again in my lifetime, will I be beholden to one of these suppliers and find myself in this position again. It’s the fuel that feeds this FUD and keeps a lot of software providers and services partners in business.
One of my favourite commentators is Corey Quinn from The Duckbill Group. If you haven’t seen his talk on multi-cloud I can highly recommend it: The Myth of Multi-Cloud, found on YouTube. He says,
“In theory, the idea of infrastructure that can be deployed between different cloud providers is a wonderful concept. Who wouldn’t love to migrate workloads seamlessly between providers for a variety of reasons? In theory, a tiger with an anger management problem is just a scaled-up house-cat.”
The short version is, that like-it-or-not, there will always be lock-in. You might be locked-in to one or two, or 12, or 100 vendors. But, depending on your definition of lock-in, you are already locked-in to each one. So, assuming I am already locked-in, the next reasoning is avoiding putting too many eggs into one basket. The fewer the vendors, the fewer the number of baskets. And herein lies the fundamental misconception.
As a business, do I benefit from more baskets, because it gives me the illusion of increased negotiating power?
If I split my workloads between providers, you might think you’ll keep them all honest because they’ll all be scared you could change your vendor mix at any point. This misses a key point though. Whether we like it or not, our importance to a vendor is consummate with the amount of business we are doing with them. If I split my cake three ways, I’m a small fish to each. If I give all (or most) of my cake to one of them, suddenly, I am now a bigger fish and worthy of increased investments, and indeed larger discounts.
As a customer though, I still have that red button by my side. Whilst going deep with a primary vendor might make it slightly challenging to move to someone else, the reality is, it’s not actually that hard. If some business-partnership-ending event occurred between you and a given vendor, you could take everything you had and move it somewhere else. Either back on-premise, or to another hyperscaler.
The idea that you could or indeed would want to do this at the drop of a hat is quite ridiculous. Whilst it might be theoretically possible to move my entire ERP system from Amazon to Microsoft on a Monday morning and then back to Amazon on a Friday afternoon, in what parallel universe would anyone think this was a good idea? So, by all means, plan for that theoretical move. Map the services between providers. I’m using Azure Functions for this; these are the config/code changes I would need to move this to Lambda in the future, should I need to. But don’t build all this complexity, all this infrastructure, all this apparatus to protect against a theoretical falling out, which hasn’t even happened and hopefully never will.
So what do you suggest?
If you haven’t picked up on the subtle cues and hints, I’m not a fan of hybrid, multi, hokey-cokey cloud. I’m a fan of one thing: simplicity. Because when we achieve simplicity, IT can melt away and become invisible, and organisations can focus on their purpose in life, creating amazing experiences for their customers and partners. I suggest you go deep with one provider – naturally I’d suggest Microsoft but I hear others are available. By doing so, you can rid yourself of complexity and create consistent, unified, control and data planes. No more incompatible products and services. Everything that just works as easily as clicking next, next, next.
Are there challenges with this approach? Sure. Are their wounds we need to help heal? Absolutely. Whatever reasoning and rationale you use as part of your decision, my most critical piece of advice is don’t use lock-in as the reason. Lock-in is the true myth of hybrid and multi-cloud. It’s already everywhere. Creating complexity for complexity’s sake neither solves nor eliminates this core tenet of the FUD we read about each day.
When we achieve simplicity, IT can melt away and become invisible, and organisations can focus on their purpose in life, creating amazing experiences for their customers and partners
