We are more or less familiar with the DevOps concept – a new methodology of team building and software development. What many of us are not aware of are the different kind of DevOps teams and how they fit into an organization. I was inspired to write this post by a Matthew Skelton presentation.
The DevOps idea brings in a new quality by introducing cross-functional teams. While we already know this concept well (at least from Agile) it has been pushed to a new level – development and operation people forming one team, fully responsible for programming, integrating, testing, installation on production and maintaining a system (OS and lower layers included). The whole methodology is based on 5 pillars:
- communication – facilitated due to merging separated teams into one,
- collaboration – throwing issues over a wall between development and operation teams has been eliminated. The same tools can be used, build pipelines can be created and maintained together. A team can share a common goal and vision,
- integration – better collaboration facilitates integration. More issues can be caught before releasing to production, production problems are also handled faster. It is easier to satisfy both development and operation needs,
- automation – teams automate everything that would bring benefit: unit and acceptance tests, possibly other tests, deployments preparation, releasing to production, logs aggregation, monitoring, reporting, measurements,
- measurement – automated metrics such as number and frequency of software releases, amount of defects, mean time to repair, time/cost per release, revenue/profit impact of outages and performance issues.
DevOps can be implemented in many different ways.The way of team creation described above may not be suitable for many organizations and situations. It is not always the best solution nor is it even possible to form such a team. To have a wider spectrum check out the 4 patterns of DevOps topologies below (taken from this presentation).
- Typical DevOps team
The team consists of both developers and operations people. Possibly, most of them are skillful and experienced in both technical fields. They are sharing common goals and vision and use the same tools. They are as a whole responsible for the product.
- Dev and Ops close cooperation
Two separate teams in an organization hierarchy exists. However, they are working closely together to achieve common goals. Possibly part of the Ops team is sitting with Devs and vice versa. They share some tools. Requires good collaboration, cooperation and relations between both teams.
- Infrastructure as a Service
Ops team delivers standard infrastructure and catalogue of services. Devs team contains a few DevOps people who are able to skillfully use features provided by Ops and handles team needs which are outside of the scope of Ops services. There are some tools which are shared between both teams. An example is a company which has datacenters and server rooms located in a different continent than the development offices.
- DevOps as a Service
Two separate teams exist. Ops people for a specific amount of time are assigned to dev projects and assist them in their goals. They may act as a bridge between both teams. They should have well developed communication and collaboration skills. They should also understand well development and operations needs so they will be able to meet them all.
Here are 4 devops team topologies presented by Matthew Skelton. I can imagine that many companies have some sort of combination of them or even more exotic setups. Nevertheless, it is a great generalisation showing how your organization might adopt devops methodology. No matter if your company is using devops, sketch out its structure using the above method. Bring your colleagues also. You will have a chance to trigger a great discussion and generate a few interesting ideas.