I've seen a general blurring of the lines between these roles. But a common theme is that if you have a dedicated "role" for something, they will prefer tools

I've seen a general blurring of the lines between these roles. But a common theme is that if you have a dedicated "role" for something, they will prefer tools which cater to their "role". This is both a good thing for companies who benefit from further optimization within that "role", and a bad thing for companies who do not. Kubernetes is a powerful tool for "DevOps" roles. It provides an immense array of configuration, and largely replaces many OpenStack, Xen, or VMWare type environments. You can build powerful internal workflows on it to colocate many services on one compute fleet while maintaining developer velocity - which can translate to large margin improvements for some firms. This comes at a cost that you are likely to need a Kubernetes team, and potentially a dev tooling team to make it all work. On a large compute environment, the latter costs don't effect the big picture. Now on the other hand, more teams than you would expect are just fine on Heroku/AppEngine/AppRunner/Lambda. These teams tend to pay the cost of not having a dedicated dev tooling team through more expensive compute, and sub-optimal tooling. The benefit here though is that "more expensive compute" may mean a fraction of a salary in many environments, and "sub-optimal" tooling may mean a production grade SaaS offering that has a few rough edges you talk to the vendor about. IME it's much cheaper/lower risk to choose the latter in the long-run. The apparent savings from option 1 eventually turn into tech debt as the shiny tools get old, and migrating to newer/cheaper compute options becomes more expensive. I once built a colo facility which resulted in a 4x reduction in monthly recurring expenses (including salaries) for the same compute footprint, 1 year into the lifetime of the facility the former cloud provider reduced prices by ~30%. Around 6 months into the facility the DataScience team suffered attrition, resulting in fewer compute needs. At the 1.5 year mark the team begged for a flip to SSDs as they were having latency issues (a point of initial contention with the team that SSDs should have been used in the first place). Over the 3 year expected lifespan of the facility there were about ~2.5 months of ramp up/migration work which impacted ROI. Overall, in hindsight, I'd say at best we achieved a 1.5x reduction in compute expenses compared to the alternative of tooling improvements, cloud cost reductions, and compute optimization. I now seek the tool which provides the lowest friction abstraction as at the worst case I can simply migrate to something cheaper - investing in compute infra has a crazy level of depreciation.