I help people run their systems.
Clients that use cloud consistently end up spending more on devops resources, because their setups tends to be wastly more complex and involve more people.
I help people run their systems.
Clients that use cloud consistently end up spending more on devops resources, because their setups tends to be wastly more complex and involve more people.
I've worked on both kinds of companies in almost 25 years and I can confirm this is true.
The biggest ops teams I worked alongside were always dedicated to running AWS setups. The slowest too were dedicated to AWS. Proportionally, I mean, of course.
People here are comparing the worst possible of Bare Metal with "hosting my startup on AWS".
This is a toupee situation. Every effective company I've worked at has a slim platform team that might make some nice company specific templates for how to deploy, but individual teams were responsible for creating and owning their infra. The idea of having an AWS ops team is absurd if you're not at a truly massive company (XX,000+)
The "AWS ops team" is often 1-2 people and often part of the dev team formally, often augmented by external consultancies like mine. You start seeing that kind of structure in teams with 10+ people when the dev created infra starts collapsing under its own weight and they realise they need people with actual ops skillset.
I have literally never seen this at 20, 400, or 3000 engineers. But the companies that I've worked at have all been "name brand" or startups on the path to acquisition.
I've literally seen this at many dozens of companies, including both "name brand" and startups on the path to acquisition.
Same difference. Just because the huge amount of AWS work is distributed among other teams doesn't mean it's less work.
AWS in 2025 is way more work than Heroku/Fly/Vercel, but also more way work than renting bare metal from say Hetzner/OVH, and perhaps even more than renting colo.
This is only true if you're not using value added services. In my experience, teams that don't accelerate by adopting cloud won't use something like SQS or Fargate, they'll throw an MQ on a k8s cluster and get enraged when it doesn't work how they expected.
I literally right now have two customers I'm working to untangle from "value added" services because they've become a threat to the financial viability of their services vs. running their own alternatives.
AWS services are great quality, but they are extremely expensive.
I have never, ever seen dev-created infra that was well done, much less with repeatable IaC. It’s always résumé-driven nonsense based on whatever someone read on blogs, and they have no clue how any of it works, only that the output what they expect.
Could definitely be skewed by my time at AWS and working for companies that hire ex-AWS people, but I've never seen infra being the real third-party roadblock. I've always seen a design review -> IaC creation pipeline that's relatively fast.
Recently I've seen a lot of IaC created by dev, unfortunately. All vibe-coded, of course.
> The biggest ops teams I worked alongside were always dedicated to running AWS setups. The slowest too were dedicated to AWS.
I wish I could come up with some kind of formalization of this issue. I think it has something to do with communication explosions across multiple people.
Increases in complexity exponentially increases mistakes + MS Teams meetings are just a glorified game of telephone.
Don't make perfect the enemy of the good.