"Move to the cloud."
If you worked anywhere near technology in the last fifteen years, you heard this. Probably from a consultant. Probably accompanied by a slide deck with a lot of blue gradients and the word "transformation."
The pitch was simple, and honestly, it was good: put your stuff on the internet so people can access it from anywhere. Your email, your files, your applications — reachable from a laptop in a hotel room or a phone on a job site. Real value. Easy to understand. Easy to justify.
That is not what happened.
The Bait and Switch
What "move to the cloud" actually became was "move everything to one of three companies."
Your email? Microsoft or Google. Your documents? Microsoft or Google. Your hosting, your databases, your file storage, your background jobs? AWS, Azure, or Google Cloud. Pick a vendor, start building on their proprietary stack, and hope you never need to leave.
The promise was access from anywhere. The product was dependency on someone.
And the way it was sold — especially to traditional industries, manufacturing, logistics, construction, steel — was fear. "You can't manage this yourself. The security risk is too great. What if something goes wrong? What if you get hacked? What if a server goes down at 2 AM and nobody's there?"
These are real concerns. But they were real concerns before the cloud, too. Companies managed servers. Companies had IT staff. Things went wrong and people fixed them. The internet didn't spontaneously combust every time a company ran its own email server.
But the pitch worked, because traditional industry is legitimately terrified of technology risk. They don't understand it deeply enough to evaluate it, so when someone in a nice suit says "let us handle it," the relief is worth almost any price tag.
And the price tag turned out to be enormous.
The Job That Didn't Need to Exist
Here's a fun one. The cloud was supposed to make things simpler. It was supposed to abstract away the hard parts of running infrastructure so developers could focus on building software.
Instead, it created an entirely new engineering discipline.
The DevOps engineer. The highest-paying individual contributor role in most tech organizations. A position that exists for one reason: the cloud platforms are so complicated that you need a dedicated specialist just to operate them.
Think about what that means. We moved to the cloud to reduce complexity, and the result was so complex that we invented a new job title — and made it the most expensive one — to manage the complexity we just created.
Before the cloud, developers were closer to the machine. I started in this industry when part of being a dev was understanding how to SSH into a server, change your PHP settings, configure Apache or nginx, manage your own deployments. Not because we were cowboys — because that proximity to the actual server was valuable.
When you're working directly on the machine that's running your software, you understand where it breaks. You can tail a log file and watch requests come in. You can see memory climbing in real time. You develop intuition for how your system behaves under load, because you're standing right next to it. It's the difference between watching a machine on the shop floor and reading a dashboard about it from across town.
The cloud replaced that proximity with abstraction layers. Log files became log aggregation services. Server metrics became observability platforms. Deployments became CI/CD pipelines with fourteen steps and a YAML file that nobody fully understands. Each layer has its own learning curve, its own pricing model, and its own team of people insisting it's essential.
And now the only people who understand the full picture are the DevOps engineers, who cost $180K a year and are backlogged for six months.
The Risk That Didn't Change
The original fear pitch went something like this: "You can't have developers SSH-ing into production servers. That's a security risk. Someone could go rogue. Someone could accidentally delete the database. You need proper controls."
Fair enough. Those things can happen.
But I've been in this industry for 17 years, and I don't remember hearing stories of developers going rogue and destroying company servers at any rate greater than I hear about rogue employees sabotaging cloud installations. Leaked credentials. Misconfigured storage buckets that exposed customer data. IAM policies left wide open because nobody on the team fully understood them. Entire organizations locked out of their own infrastructure because someone made a bad change to a deployment script.
These are cloud-era problems. We traded one risk profile for another. The threat of a bad actor didn't go away — it just moved to a platform that costs ten times more to manage.
The risk didn't change. The price tag did.
And this is the part that should make every CFO in traditional industry furious. You're paying a massive premium for risk management, and the risk isn't actually being managed differently. It's being managed elsewhere, by people who are making margins that would make your head spin, while telling you that the alternative is chaos.
The Lock-In Machine
Every cloud platform has a version of this pitch: "Don't run nginx on a VPS. Use our serverless function instead." "Don't connect to the database with an IP and a password. Use our IAM system. It's more secure."
Each of those decisions sounds reasonable in isolation. Each one is another bolt in the cage.
Don't use a file system — use our object storage with our SDK. Don't run a message queue — use our managed pub/sub service. Don't write a cron job — use our event scheduling system. Each one locks you deeper into the ecosystem. Each one makes it harder to leave. And by the time you realize you want to leave — because prices went up, or service quality went down, or a competitor does it better — you'd need to rewrite half your infrastructure to make it happen.
That's not a side effect of the cloud. That's the business model.
Ask your average dev team how long it would take to migrate their stack to a different provider. The answer will never be "a couple hours." It should be. But it won't be, because they've built on proprietary services that don't exist anywhere else.
I know this because I've lived the alternative. A few years ago, a VPS provider had an outage — our staging server went down. Third time that year. I told my team: "I bet I can migrate this to another provider before it comes back online."
So I did. Database, file storage, several Node.js services running on nginx with pm2. A couple hours, start to finish. The staging server was running on a new provider before the original one came back online.
That's only possible because the stack was simple. Standard tools. No proprietary anything. The database had a connection string. The files were files. The services ran on nginx. There was nothing to "unwind" because there was nothing vendor-specific to begin with.
That's what portability actually looks like. And it's the thing the cloud is designed to prevent.
The Shiny Object Problem
I'd be dishonest if I laid all of this at the feet of the cloud providers. Engineers are complicit.
We love new things. A new framework, a new language, a new deployment paradigm — it doesn't matter if the old thing worked fine. The new thing is interesting, and interesting is hard to resist when you spend your entire day solving the same kinds of problems.
Microservices are a perfect example. Somewhere around 2015, the entire industry decided that monoliths were dead. If your application wasn't decomposed into a dozen independently deployable services communicating over message queues, you were doing it wrong. The fact that this architecture was designed by companies with 2 billion users and 10,000 engineers didn't matter. If Netflix does it, we should too. Never mind that your app has 400 users and three developers.
Serverless was next. Then containers for everything. Then service meshes. Each was a solution to a problem most teams didn't have, adopted because it was new and because the conference talks made it look elegant.
I'm not immune to this. I love trying new things. But I've been doing this long enough to know that a boring stack that works is worth more than an exciting stack that requires a consultant to explain.
And that consultant economy is its own industry now. AWS certifications. Azure bootcamps. DevOps tooling companies. Observability platforms. Managed Kubernetes providers. Every one of these businesses has an incentive to tell you that the old way is dangerous and the new way is necessary. That's not a conspiracy — it's just margins. Everybody's making money on the complication.
The Playbook Repeats
And now it's happening again. Same playbook. Different product.
AI companies are running the exact same lock-in strategy that cloud providers perfected a decade ago. Build your app ON Copilot. Build your app ON Gemini. Build your app ON ChatGPT. Not with these tools. On them.
The fear pitch is identical: "Your data is valuable. Your data is sensitive. You can't just let anyone process it. Build on our platform and we'll handle the risk."
And just like the cloud, the result is dependency. You build your AI features on one provider's API, using their function-calling format, their embedding model, their vector store — and now you can't leave. You're locked in. Again.
This is especially dangerous right now, because AI models are not interchangeable. They have meaningfully different strengths and weaknesses, and those strengths shift with every release cycle.
I build apps with AI components regularly. Here's what I've observed: marketing users tend to prefer ChatGPT. Technical users gravitate toward Claude. Gemini does the best job chaining tool calls together. Claude does the best job conducting research and adhering to data structures. Those are real, meaningful differences. And they change — a model that's best-in-class today might fall behind next month when a competitor ships a new release.
When I build an AI feature, I write an adapter layer. Every frontier model and every open-source model through an open-source inference provider, all behind a single interface. Often I let the user choose which model they want, because users have preferences and those preferences are usually right for their use case.
That's portability. That's what "the cloud" was supposed to mean, applied to AI.
But portability isn't what the AI companies are selling. They're selling the easy button. Turn on Copilot for your organization. Give it access to your documents and spreadsheets. Ask it questions about your data. One click. So simple.
And it is simple. Right up until Microsoft doubles the price and you literally can't leave, because too much of your business depends on a feature that only exists inside their ecosystem. Right up until you realize that Copilot is great at some things and terrible at others, but you can't swap it out because you've built your workflows around it.
Here's my prediction. Right now, somewhere in a big organization, someone is saying: "I'd love to ask our AI about our inventory data, but that data lives in a different system. Is there a way to make that work?" And a consulting firm is going to walk through the door and say: "We can make that happen. Eight figures, six months."
And what they'll deliver will be 30% as effective as it could be. Because the consultants will offload the risk to yet another proprietary platform, which will limit the integration to protect its own liability, which will restrict what queries actually work, which will create yet another dependency that's even harder to unwind than the last one.
Same playbook. Bigger invoice. Different decade.
The Actual Point
I'm not saying everyone should go back to SSH-ing into servers and managing their own mail. I'm not saying the cloud has zero value. I'm not saying AI platforms are useless.
I'm saying the tech industry figured out something powerful about twenty years ago: traditional industry is afraid of technology risk, and that fear is worth a fortune.
The cloud was sold as freedom and delivered dependency. The margins on that dependency are three to four times what traditional industry earns doing actual physical work. And now AI is being sold the same way — build on our platform, let us handle the scary parts, don't worry about what happens when you need to leave.
Your website doesn't need hyperscale. It doesn't need Kubernetes. It doesn't need serverless functions or a service mesh or a managed container orchestration platform. Ninety-eight percent of the internet could run perfectly fine on 8 gigs of RAM and two CPUs on bare metal with a reliable connection. Even running the latest technologies. You can write scripts to handle crash events and logging and restarts. This stuff is not difficult.
But someone told you it was. And someone is making a killing because you believed them.
The answer — for the cloud, for AI, for everything — is portability. Simple tools. Standard interfaces. Adapter layers. The ability to move when you need to move. The ability to swap one provider for another in hours, not months.
The companies selling you complexity have an incentive to keep you locked in. The consultants explaining the complexity have an incentive to keep it complicated. The engineers implementing it have an incentive to keep it interesting.
Nobody in that chain has an incentive to tell you the simple thing would have worked fine.
So I'm telling you.