You know you have a problem when, in the middle of the night, you sit in front of a screen filled with error messages you can't find in the documentation and therefore need to scour the internet to try to decipher. You have created a support ticket that rests peacefully in a queue where it should have been you resting in bed. That's probably when you realise the unpleasant fact that you are not really in control of your cloud infrastructure. You are just a tenant and the landlord has the keys.
That is the day to realise the alternatives and stop caring about cloud vendor lock-in.
We've all been sold the same dream: "Just use our managed services! It's easier! It's faster! It scales with a single click!"
It is easier – until you realise you've moved into a walled garden that feels more like a gilded cage. Everything is polished, the APIs are convenient, and the console looks beautiful. But as you scale, the freedom to choose your tools – or your infrastructure provider – slowly evaporates. You aren't just a customer; you're an extension of their proprietary roadmap. In the context of the European digital landscape, where issues like Digital Sovereignty and strict data compliance are no longer optional, this "managed" convenience can quickly turn into a significant business risk.
To be clear: I am still a huge believer in Cloud-Native technologies like Kubernetes but realised there is a difference between "Cloud-Native" (the open-source foundation) and "Cloud-Locked" (the proprietary managed services).
It's time to stop caring about the marketing buzzwords that force us into a single vendor's ecosystem, and start fighting for the open-source sovereignty that lets us build, move, and grow anywhere, which brings us to the perceived Nirvana of independence, Multi-Cloud.
Everyone talks about a "Multi-Cloud Strategy."
It sounds sophisticated, doesn't it?
But in reality, for 90% of teams, it's just doubling the complexity.
If your application relies on Vendor A's proprietary secrets manager and Vendor B's specific load balancer API, you haven't achieved multi-cloud. You've just achieved "multi-headache."
True multi-cloud isn't about using five different providers; it's about mobility, being able to run your stack anywhere without rewriting your code and resilience, should one provider be down, you can easily run your services at another provider.
At Obmondo, we stopped looking at the cloud as a destination and started looking at it as a utility.
Our mission – and the reason I'm so passionate about projects like KubeAid and LinuxAid – isn't to say "don't use the cloud." It's to say, "use the cloud, but don't let it own you."
Sovereignty is about control.
It's about having an abstraction layer that treats your infrastructure as code, that works the same way on a bare-metal server in a basement as it does on a massive cluster in a public data-centre. You configure your setup once with a manifest in a Git repository and deploy it wherever you want.
When you use open-source tools to standardise your stack:
You don't have to burn your cloud accounts to the ground today; but you should start asking yourself: If my current provider doubled their prices tomorrow or decided to change their service model, could I move my entire production environment in a week?
If the answer is "no," you have work to do.
Start small. Standardise your OS configurations. Decouple your secrets management. Use open-source GitOps patterns that don't rely on a provider's console.
Infrastructure shouldn't be a vendor lock-in strategy; it should be the foundation you build your legacy on.
Don't be a tenant. Be the owner!