You build it, you run it
It’s powerful, well-balanced, and rooted in common sense. This phrase, which later became a DevOps mantra, sums up the approach of Werner Vogels, Amazon’s CTO. The quote dates back to 2006:
The traditional model is that you take your software to the wall that separates development and operations, 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 also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.
But as we know, common sense is the most widely shared thing in the world, so two or three arguments are always welcome to support the point.
Werner Vogels suggests empowering development teams: you don’t let a support team handle the 💩 you’re responsible for, because that’s an incentive to keep creating new ones. Losing sight of the user is the source of many problems in IT: it opens the door to unnecessary complications, which is the opposite of the pragmatism that drives the business forward. So we need to “internalize externalities,” as the kids say.
It’s also a way to better manage deadlines: “it works on my machine” is no longer an acceptable excuse. It’s up to you, developers, to anticipate the critical step of the production rollout from the very start of the codebase (in fact, during the walking skeleton phase). This is to avoid discovering at the last minute (with three months to go) that you still need to implement authentication, application permission management, and log management—and that you actually have no idea how to deploy your application 🙄
But I would say that Werner Vogels’s call to action is directed first and foremost at those—particularly CEOs—who shape organizations: for them, it means avoiding putting obstacles in the way of their teams with a structurally flawed organization. It’s all well and good to empower developers, but we must still avoid contradictory directives. They lead to burnout among even the most dedicated individuals.
We know it, and we’ll say it again: creating a “Production” team doesn’t work, nor does a “Support” team (a jack-of-all-trades team), nor even a DevOps team (try that again): it distances developers from the business objective and creates silos.
Why is it so tempting to create such teams? Because the company wants to streamline costs, avoid an uncontrolled proliferation of technologies, promote security best practices, and so on.
So how can we meet these needs, which of course don’t magically disappear when we finally decide to break down the silos?
As is often the case, it’s subtle: you have to lead, supervise, and perhaps enforce certain standards—without, however, taking the place of the development teams. This involves shared code libraries, architectural and security standards, but above all, awareness-raising and training. In other words, a whole range of cross-functional initiatives that complement the product-oriented organization mentioned earlier.