> But despite a lot of effort, the vast majority of organisations couldn’t make this ideal work in practice, even if they tried.
This matches my on-the-ground experience. The teams who lived the dream of DevOps were teams which built their software as cloud native (instead of later trying to migrate to the cloud). This is purely because the PaaS tooling let them efficiently be both Devs and Admins.
When you involve many teams instead of just a smallish group of devs, you have momentum to deal with. Plus, specialization - some of these ops people just don't like coding, or at least not the kind of coding you need to be doing to be effective DevOps engineers.
Indeed this leads to SRE - just because "Buying it" is usually easier than "Building it".
Indeed. I think the other big elephant in the room not mentioned in the article is architecture.
If you've built your project as cloud-native from day one, you'll have a lot less DevOps work to do. You're basically just writing code or templates that apply cloud-based configuration. That's not to say there's no complexity, but it's not unreasonable.
If your org has already gone all-in on microservices and Kubernetes, there is a much stronger case to be made for centralized Ops. The amount of understanding, care, feeding, and training necessary is much higher. You won't be able to get by with one or two contributors occasionally making changes to Terraform templates as necessary. Clusters are expensive, require occasional upgrades, and centralized metrics and logging don't come for free and require their own access control. It's still better than it's ever been, but it's a lot like building and maintaining your own cloud, which quickly becomes a full-time job.
If the team building the application is designing the infrastructure, then that's almost the DevOps ideal that orgs dream about. It's really the stuff that happens once you've been launched for a few months that things start to drift. It might start with a redirect rule that isn't in code, an ask to do cost optimization, a security audit. Maybe one dev raises their hand and a few months later they're the DevOps lead with a DevOps team who become the dumping ground for all the non-coding task, on-call, budgeting. Even if your platform is all PaaS and SaaS and serverless, stuff will still break and someone needs to answer the pages.
> The teams who lived the dream of DevOps were teams which built their software as cloud native
Or the total opposite. People that not drink the cloud-narrative and the operational simplicity make devops no-brainer.
ie: You are truly made for the massive overenginering of cloud (because you ACTUALLY need that) or you keep things simple enough to fit in a single head.
What is problematic is when you try to do be first, or present to be second.
The immediate following sentence from the one you quoted was:
> This is purely because the PaaS tooling let them efficiently be both Devs and Admins.
It wasn't the cloud which made them successful, it was the level of automation baked into the PaaS solution(s) they built on top of. I thought I was pretty clear on that, but I suppose I could have been more clear.
You could similarly get success if you had an OnPrem solution with really great orchestration layers. And in fact, I've heard of such successes (but not seen up close) of teams doing exactly that with Pivotal Cloud Foundry.
This matches my on-the-ground experience. The teams who lived the dream of DevOps were teams which built their software as cloud native (instead of later trying to migrate to the cloud). This is purely because the PaaS tooling let them efficiently be both Devs and Admins.
When you involve many teams instead of just a smallish group of devs, you have momentum to deal with. Plus, specialization - some of these ops people just don't like coding, or at least not the kind of coding you need to be doing to be effective DevOps engineers.
Indeed this leads to SRE - just because "Buying it" is usually easier than "Building it".