Cloud Lock-In: 2019 → 2025
Five years ago, I wrote that "cloud native" would become the next vendor lock-in cycle, not an escape from it. Here's what happened.
What I Wrote in 2019
In August 2019, I argued that enterprises were about to overcome their fears of cloud lock-in—not because those fears were unfounded, but because they were focused on the wrong layer.
Everyone was worried about being locked into AWS, Azure, or GCP at the infrastructure level. The real lock-in, I said, would happen at the service layer: managed databases, serverless functions, proprietary APIs, and orchestration platforms that made portability effectively impossible.
The thesis was simple: Organizations would adopt "cloud native" architectures believing they were building portable systems, only to discover they'd created tighter coupling than the mainframe migrations they'd just escaped.
* * *What Actually Happened
By 2025, multi-cloud became the stated strategy for nearly every Fortune 500 enterprise. Almost none of them achieved actual portability.
What they got instead was multi-cloud presence—workloads running on multiple clouds, but each workload locked to its host through managed services, proprietary APIs, and platform-specific optimizations.
The Pattern Repeated
The lock-in didn't come from raw compute or storage. It came from:
Managed service adoption. Teams chose DynamoDB, CosmosDB, or Cloud Spanner because managing distributed databases is hard. The databases worked brilliantly—and became unmigrateable.
Serverless proliferation. Lambda, Cloud Functions, and Azure Functions promised infinite scale and zero management. They delivered both, along with vendor-specific event models and deployment pipelines that made portability a rewrite, not a refactor.
Identity and access integration. IAM roles, service principals, and workload identity became so deeply embedded in application architecture that moving clouds meant redesigning security models from scratch.
Observability platform capture. CloudWatch, Azure Monitor, and Google Cloud Operations became the system of record for operational intelligence. Moving workloads meant losing years of baseline data and learned behavior.
The Economic Reality
Organizations discovered that "multi-cloud portability" cost more than single-cloud lock-in. Maintaining abstraction layers, testing across platforms, and operating redundant toolchains consumed budget faster than cloud bills themselves.
So they chose strategic lock-in. They bet on providers. They optimized for the platform, not against it.
This wasn't failure. It was recognition that portability has a price, and sometimes that price exceeds the risk.
* * *The Pattern That Holds
This is what repeats across technology cycles:
Abstraction promises freedom. Every new platform arrives claiming it will eliminate lock-in from the previous generation. Containers were supposed to free you from VMs. Cloud was supposed to free you from datacenters. Kubernetes was supposed to free you from cloud providers.
Optimization creates coupling. The moment you optimize for the platform—and you must optimize, because generic deployments don't survive production—you create lock-in. Not at the layer you're abstracting, but at the layer above it.
Value accrues to managed services. The winning move isn't portable compute; it's managed intelligence. The cloud providers that win aren't selling VMs—they're selling managed ML pipelines, real-time analytics, and auto-scaling databases that would take years to replicate.
Lock-in becomes a feature, not a bug. Eventually, organizations stop trying to avoid lock-in and start negotiating its terms. The question shifts from "how do we avoid this?" to "what commitments do we get in return?"
* * *Why This Matters for Autonomous Agents
If you're evaluating AI agent platforms, governance frameworks, or orchestration systems, pay attention to this pattern.
The vendors will promise portability. They'll show you abstraction layers, open APIs, and multi-provider support.
Then they'll offer managed capabilities that make everything easier—hosted models, integrated workflows, proprietary optimizations. You'll adopt them because the alternative is building everything yourself.
And six months later, you'll discover you're locked in. Not to the compute layer—that's still portable. But to the governance model, the audit trails, the policy enforcement patterns, and the intelligence layer that makes the whole system work.
The question isn't whether you'll get locked in. You will.
The question is: Are you locked into something that adapts with you, or something that forces you to adapt to it?
That's the decision that matters. And it's the same decision enterprises faced with cloud in 2019.
← Back to Patterns That Repeat