| Come on, this is such a joke. Increased velocity is what business get promised, yes. It’s what you want. The reality is that you can’t just magically make that happen. Draw a line. Now draw the rest of the owl! Easy~ The problem has never been understanding what the desired state is… it’s always been that getting from the current state to the desired state is very very hard, and continually road blocked by: - people who don’t want to learn new skills - people who don’t want to seed control they currently have (over process and product) - a lack of clarity on who is responsible for what systems Devops is a load of hype. There’s never been any reliable process to move to rapid delivery from it. Yes, some teams have managed to get something that works, and there are a lot of tools and a lot of training which has resulted in over all better SRE processes. …but by and large, that’s because of using better tools (eg. infrastructure as code) not because of devops. When was the last time you had a “devops” guy you got to do something for you? Right. That’s ops. When was the last time something broke and the people responsible for making sure it never happened again were the “platform team” or an SRE? Ops again. You had all that before you started your devops journey. It’s all just ops, with slightly better tooling, less outages, higher reliability and absolutely zero increase in product velocity. Devops was the promise that by bridging operations and development you could get high reliability and faster iteration by having teams that could “cut through” the red tape and get things done. That appears, largely, not to work. Yes, developers that understand systems tend to build more reliable software. No, it is not faster to do it that way, and the transition will be painful, and, because businesses mostly care about iteration speed more than reliability, even a technical success, it often a fails to deliver on its business value. |