I’m mildly annoyed by the type of pseudo-coherent thoughts that are apparently the norm around the idea of DevOps: “DevOps is a philosophy,” “DevOps is obsolete,” “Platform engineer is the new term,” blah blah.
Here’s a timeless way to look at it, free of all hype and buzz, a take that’s as true now as it will be 100 years from now:
Software, like all systems, gets harder to operate the bigger it gets. Eventually you hit a point of what I’ll call, meta-engineering, meaning re-engineering the process of engineering.
In practice, forms of meta-engineering include: testing, REPL, reuse, deployment/reverting, measuring/observability, and most things that would get put under “DevOps.”
And the point is this — there are no neat boxes. Depending on the project value of meta-engineering in each of these areas may range from irrelevant, to worthy of an out-of-the-box-solution, to being worthy of more focus than the feature team. And the needs of problem rarely align in generic ways that neatly align with OCD org-charts.
Any attempt to make hard-and-fast rules (each company should have an X team that uses Y% of the budget and is split into Z sub-teams) will be clumsy and likely erased by a new philosophy in less than a decade, as the software ecosystem changes.
So instead of producing abstract semi-coherent takes like “DevOps as a whole is …” it’s better to gather hard data on your specific company’s needs and just identify the areas that have a positive ROI for meta-engineering.
This isn’t a sexy take, it’s not one that you can debate endlessly, and that’s what part of what makes it good.