It is, but it's difficult to introduce. Just hiring 'devops' people for your ops team, or giving developers access to AWS is missing the whole damn point. It re

It is, but it's difficult to introduce. Just hiring 'devops' people for your ops team, or giving developers access to AWS is missing the whole damn point. It requires reorganizing work in a way that makes a lot of people angry, as they now have to do things that so far they've just tossed over the wall to another team and then complained loudly when that didn't work. You have to convince developers that they're responsible for making software easy to deploy and debug, and get them to carry pagers during work hours. You have to convince them to make the product internals clear for everyone, including to operations people, and get them to do knowledge exchange with them. You have to enable them by providing insight into production deployments and providing a platform that unifies production/development as much as possible without tons of boilerplate required per project (common database interfaces, common logging interfaces, common CI, common release procedures, common development environment). You have to convince operations teams to write programs in something other than bash, and to generally follow good software engineering practices, to write operations-level code that is as testable as the application itself. You have to enable them by giving them the means to build a company-wide production platform where complexity is decimated by moving every product team onto the simplest possible setup. You have to let them build bespoke tooling and accept that these lines of code are as important as the application code itself. With all of this implemented well, the differences between ops and dev roles will begin to blur, people with different backgrounds will mingle within and across teams, and you will end up with a more platform/product split between teams rather than a development/operations split.