We’re all quoting it over and over again: “You build it you run it”. Few comments in our industry had such a vast impact on an entire generation of developers.
In this conversation with Jim Gray from 2006,Werner Vogels says: “The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software.”
It felt like such a simple answer to solve the tension between developers and operations, which is a complex problem in the enterprise.: And Vogels is an authority, right? I mean he’s the CTO of freaking AWS, our daily bread, and governor over an army of developers. If anybody, he should know. Armies of DevOps consultants can now march out and retrain half the population. So much to learn for the average dev, finally! And whoever doubts this will get shut down with sentences such as “you want to take context away from developers”, “you obviously have no experience, otherwise you would know that developers HAVE to understand the lowest networking config to know how their service will run”.
Let me do something that will not go down well with some. That is to question Vogels. Not the man we know today, but the context of the man he was in 2006. Vogels starts his career as a researcher, became a Director of System Research in 2004, and Amazon's CTO in 2005. At the end of 2005 Amazon was a small company compared to the usual enterprises we work with, with less than 8,000 FTEs. I don’t have the exact numbers but it’s fair to assume that this was a small team of developers (a few dozen, several hundred max) that worked on the webshop.
At the same time, the “digital world” wasn’t remotely as complex as it is today. No microservice architectures, a few rudimentary tools, less global distribution, less sophisticated attack surface.
While “you build it, you run it” at all costs might have worked at a small Amazon in 2006, it doesn’t work at an organization with 2,000 developers in 2023. And while it satisfied the researcher spirit of Vogels in 2006, with everyone understanding everything in detail, specialization shouldn’t be a dirty word in 2023.
This doesn’t mean we should go back to “throwing over the fence”. But shifting left at all costs and eliminating separation of concerns entirely is the wrong answer. It only leads to burnout, TicketOps, and cognitive overload. In a well rounded team, Devs and Ops never have transactional conversations, nor fight each other in a toxic relationship. Self-service is king, golden paths are king. And platform engineering is king. The fact is that most of the current DevOps setups are broken, and need to be rebuilt.
So… LONG LIVE PLATFORM ENGINEERING!
Keen for more deep dives and hot takes from the cloud native and platform engineering world? Check out the brand new Platform Weekly, which has already clocked over 4k subscribers in a few weeks.
Kaspar
