DevOps in 5 minutes

When people with development competence and operations competence collaborate throughout the whole development process, they work more efficiently, and they make better decisions. That’s why organizations that are good at DevOps, are more likely to meet or exceed their business objectives compared to organizations that are not.

The term DevOps was created in 2008, but the idea of cross-functional teams, which is the core principle of DevOps, is of course, much older. In the past 20 years, most of the software industry has realized that development and testing are not separate activities for separate teams. We have integrated development and testing into the same team, and quality is a shared responsibility. DevOps is about doing the same for development and operations, as we have done for development and testing.

Let’s look at some classic problems that DevOps can solve.

1) If development and operations are separate, and we get feedback from operations late in the development process, we may have to go back and make changes based on that feedback. That’s wasteful. Instead, we should involve operations competence during design and implementation, and not as an after-thought. Then we can make better decisions early and reduce the chance of double work and operational problems down the line.

2) If development is responsible for producing features, they are incentivized to make lots of changes to the system. If operations is responsible for stability, they are incentivized to resist changes. This misalignment of incentives can cause conflicts. It is also very problematic that the operations team often has to bear the cost of bad decisions made by the development team, whether it’s unstable software, lack of logging, etc. Instead we should follow the principles of “sharing the pain” and “you build it, you run it”. Incentives must be aligned.

3) A really bad consequence of having a separate operations team is that they won’t have the necessary context to respond effectively to incidents in Production. How could they? If they were not involved in creating the service, they will not have the appropriate knowledge about the service, the domain, the users, or the technologies involved. This means that the incident response will be ineffective, and operations may have to escalate the incident to development anyway.

My preference for solving these problems is to move away from traditional development teams and instead create Service Delivery Teams. A Service Delivery Team is not just responsible for building software, but for continuously delivering a service to the customers. A Service Delivery Team has both development and operations competence and they own both the software and the infrastructure for their system. The Service Delivery Team is responsible for everything, from design, development and testing, to deployment, monitoring, handling incidents in Production and everything in between.