I had dinner this week with a friend and colleague who took issue with some of what I said in my first post on this topic. Specifically that I may have gone too far in dismissing this definition of DevOps:
DevOps is eliminating operations altogether by "empowering" development teams to manage every aspect of their product.
I admit that this is a bit vague in that i can be read in ways that I didn't intend for my larger point. The very nature of communication means that you can always be misunderstood, but this this case it's more than that - I didn't phrase this specifically enough and my friend's critique is absolutely correct.
So what did I mean? The key part of the definition for my point is the elimination of operations, and that this is a misguided and counter-productive goal. What was pointed out to me is that a key part of DevOps is "you build it, you run it (YBIYRI)," which is something I do agree with. What I take issue with, again, is that using a YBIYRI model eliminates the need for operations expertise and operations teams.
If you look at this narrowly you could argue that YBIYRI does eliminate traditional operations because the developers are responsible for more of the life cycle of their product, including being responsible for deploying and maintaining it. They are responsible for monitoring it, and if there's an issue they receive the pages and are the first responders. This is good, and setting these expectations can help drive a more reliable product because the teams responsible for it are also supporting it and much more familiar with post-deploy issues.
Taking a broader view of this, you can see the breakdowns in the system. The YBIYRI model is great, but it doesn't address everything necessary for success. One immediate issue that organizations who have tried to go to a full YBIYRI model have run into is that by making every dev team responsible for their own deployment, monitoring, and maintenance is that each team chooses their own solutions to these tasks. Many of them will implement solutions that are different than other teams are using. Some will implement the same solutions, but without overlap - their solution will have it's own configuration and setup. A few may work with other teams to come up with a common solution, but making the individual dev teams responsible for their own infrastructure makes it difficult to leverage these commonalities. Even if all these solutions are open-source and don't require a capital outlay, you are still losing money in the time each team spends in deciding and implementing a solution, and in its ongoing care and feeding.
So YBIYRI is a bad idea? No, not at all. On the contrary, it's a very good model when done correctly. Unless your organization is very small and you have a single dev team working on a single product, everyone is going to benefit from leveraging common toolsets for operations and infrastructure. Providing a framework for deploying applications, whether in the cloud or in the datacenter, means that the dev teams immediately gain efficiency by being able to use that instead of reinventing that wheel. Likewise with other tools and processes like monitoring, metrics dashboards, system patching, container pipelines and management, log aggregation, etc.
To repeat, my larger point from my previous post is that this new world is a closer integration between dev and ops teams, not a transference of operations responsibilities onto the dev teams. If you define DevOps in terms of the YBIYRI model, that's great, just don't forget about the deeper issues of operations and how they need to be solved. You are free to call your YBIYRI teams "DevOps", and we can call the common operations, infrastructure, and tools something else. Just don't fall into the trap of thinking that they're not necessary any more. In a YBIYRI world they are absolutely necessary, but even better, in this new model they can provide many more benefits and efficiency to all parts of your engineering organization.