The Cloud, As Seen From a Data Center
2020-11-26Why Cloud Migrations Fail, Part 23424711
Four-hundred years ago on the planet Earth, workers who felt their livelihood threatened by automation flung their wooden shoes called ‘sabot’ into the machines to stop them.
Hence the word ‘sabotage’.
“Should we move to the cloud?”
This question has filled countless wells with bitter tears. And countless executive meeting rooms. About half of everything ever written on the internet is about “why cloud migrations fail” – seriously, google it, right now.
But all of it fails to address one uncomfortable truth:
There’s a saboteur. Hiding in the shadows. Hiding behind rational arguments. You know, like… Will the cloud really be cheaper? Will the cloud really propel our software release cycle to ludicrous speed? Does the cloud really make sense for our legacy applications? Does cloud really scale better? Is it really GDPR compliant1? And so on.
So many exhausting discussions revolve around these questions. They are good questions. They are quantifiable. There’s good data available on those questions – both for and against moving to the cloud. It’s almost too easy, too tempting to discuss these questions over and over: They are the perfect cover for being opposed to the cloud, without speaking about true reasons.
Then, usually, at some point, someone has to roll the dice and decide… and, somewhat reluctantly, the decision is made to move to the cloud.
But the engineers’ hearts are not in it. They don’t want the cloud. It solves problems they don’t have. Maybe they don’t even know themselves exactly what is upsetting them; they just know it’s Not Good™.
Some months down the road the whole project is clogged up. It starts to reek. Badly. The organization is half a leg into the cloud, but now everything is “kinda stalled” and nobody wants to talk about it. The saboteur is still there, comfortably at large among the company’s engineers.
That saboteur is the fear of losing control.
But nobody speaks up. Nobody wants to be the one cockblocking the company’s glorious cloud future… because of emotional issues. Because that’s how it would be perceived, right? It’s unjustified fear. It’s irrational. It’s not quantifiable. It looks like resisting change just for the sake of being opposed. And so the fear of looking silly is right there, breathing down your engineers’ necks.
On Responsibility and Trust
Here’s a confession: I’ve been there. I tried to laugh the cloud away. I tried to let it rain. I thought the cloud is a “big mistake!” (in Trump’s voice).
So let me explain where this deeply rooted need for control in many engineers comes from…
For the better part of my career I was part of an amazing engineering team at a Managed Service Provider. We built and operated hundreds of custom-designed web platforms for our customers. Among them many household names. Emergency services. Key government sites. Mostly e-commerce sites, including some of the “outages are measured in thousands of euros per minute”2 variety.
All this ran from our own data centers. We designed and operated everything – switching, internal and external routing, virtualization clusters, backup systems, storage networks, management tools, and so on. And all this was handled by one team. Looking back now, it sounds pretty crazy.
It’s scary, really: A screw-up with a single storage cluster could easily pose an existential threat to dozens of customers (and therefore, indirectly, to their employees’ livelihoods). A large-scale and prolonged data loss, or a massive data breach, might easily have made the evening news. That never happend in all those years. Still, the permanent pressure is a unique feeling.
Point being: Our customers entrusted us with running their platforms. With managing their databases. With keeping their holiest data safe and secure. And its backups. They entrusted us their businesses.
I absolutely could not have imagined outsourcing this level of responsibility to some third party. Vendors and service providers fuck up. They always find a way to shit the bed. Most of them, anyway. You can SLA and insure that all you want; once that kind of damage is done, it’s “game over”.
And that’s what gnaws on many engineers when it comes to the cloud: They fear handing over the company’s crown jewels into unknown hands. Permanently obliterating a whole database – and its backups – often is really just some fat-fingered distraction away. They feel responsible, because they know just how easy it is to fuck this up royally.
They want to protect their company. They are sickened by the thought of losing control over the most important assets. It’s like driving your daughter to that guy’s house. And that’s perfectly normal – they have no reason to trust some third party they don’t know jack about!
Change of Perspective
It took me a long time to realize something:
From those customers’ perspectives, we were that third party. They all had trusted someone else all along! We were their cloud provider. It just wasn’t called “cloud” some ten to 20 years ago.
For them, moving to a cloud provider today would be business as usual. At least on a conceptual and emotional level.3 But for companies who kept running everything on their own, maybe even their own data centers, this is a very new beast.
The key difference is trust.
It takes years to build that level of trust. To understand and apply new technology patterns, new possibilities, new problems, new failure modes. Engineers need to feel comfortable with the many complex details of this new perspective. They need to learn to sleep sound while someone else watches over their data. Remember, engineers consider scepticism an important skill!
Conclusion
Moving to the cloud is not a project. It’s not even a decision!
Cloud needs to be enabled, not forced.
The cloud is just a tool. Teams need freedom of choice in their tools.
Tread lightly. Dip toes, test the water. Encourage teams to try it4. Spread knowledge. Start with some low-hanging fruits.
Be prepared for a long journey.
It’s the only way for all affected parties to build solid trust in a new world.
Iff the time comes to talk about those big hairy migrations, the path will be clear, and there will be significant momentum throughout the organization. That’s how cloud becomes a success.
You don’t need to argue endlessly if the cloud is worth it. If it really is, it will happen – at its own pace.
Discuss and/or follow on Twitter!
-
Spoiler: It is! ↩
-
A metric that is complete nonsense – but that’s for another day. ↩
-
On other levels, there is absolutely nothing “business as usual” about this. It’s one massive undertaking. You pay big time on many axes: Money, time, nerves, security. ↩
-
This works significantly better when you have a good organizational fit, e.g. product-based teams – so yes, all those other articles on the internet do have some valid points, too. ↩