DevOps
Analysing the DevOps Silo
In the first section of this two-part series, we looked briefly into the state of IT teams before the DevOps movement gained traction, and some skills that might be useful to those looking to get into infrastructure work. In this section, we will explore different variations of DevOps teams I’ve seen, as well as, their positives and advantages.
In the trunk and leaf model, every development team has a small group of engineers, or leaves, that are partially or wholly dedicated to creating and maintaining the platform for their service or feature. These groups are members of a larger community of engineers, or trunks, that collaborate on setting standards, best practices and guidelines for the infrastructure and tooling for which they are responsible.
This model is similar to engineering organizations found at many well-known tech companies, including Spotify’s “chapters” [2] and Google’s SRE model as described by Beyer and Jones Site Reliability Engineering book. It is also ideal for teams that are looking to have closer and more dedicated working relationships with platform engineers or teams for other tech or business functions that do not fit the typical “development team” mold. Network (DevNetOps), security (DevSecOps) and business operations (DevBizOps) come to mind here.
I’ve also seen companies employ a single platform team, or a platform hub, that is responsible for maintaining the platform that powers the entire software stack of a company. Product teams consume well-defined infrastructure services from the platform team (and are therefore the spoke in this analogy).
While members of this team might provide advisory services to development teams on how to best design their software to work on their infrastructure, the onus of publishing changes to said infrastructure or tools used to interact with it, ultimately falls on the platform team.
This model is fairly common amongst small and large companies alike. This team goes by many different names, such as the “Platform”, “Production” or “Infrastructure” engineering teams. Others typically call this the “DevOps” or “SRE” team. Regardless of the name, they usually share a few common attributes:
It’s a wonderful thing to experience.
You might have heard of or read The Phoenix Project by Gene Kim. It covers much of the history I explained earlier (with much more color) and describes their journey to a lean company running on Agile and DevOps. It’s a great book.
Here are some others that are worth a read:
DevOps In Action
I have seen two common models of DevOps at work that have been effective at bridging the gap between development, operations and business outcomes. These aren’t set in stone and can vary in implementation from company to company. For more examples and a deeper discussion of DevOps anti-patterns, I highly recommend reading Matt Skelton’s blog post on DevOps team structures [1].Trunk and Leaf
In the trunk and leaf model, every development team has a small group of engineers, or leaves, that are partially or wholly dedicated to creating and maintaining the platform for their service or feature. These groups are members of a larger community of engineers, or trunks, that collaborate on setting standards, best practices and guidelines for the infrastructure and tooling for which they are responsible.
This model is similar to engineering organizations found at many well-known tech companies, including Spotify’s “chapters” [2] and Google’s SRE model as described by Beyer and Jones Site Reliability Engineering book. It is also ideal for teams that are looking to have closer and more dedicated working relationships with platform engineers or teams for other tech or business functions that do not fit the typical “development team” mold. Network (DevNetOps), security (DevSecOps) and business operations (DevBizOps) come to mind here.
Hub and Spoke
I’ve also seen companies employ a single platform team, or a platform hub, that is responsible for maintaining the platform that powers the entire software stack of a company. Product teams consume well-defined infrastructure services from the platform team (and are therefore the spoke in this analogy).
While members of this team might provide advisory services to development teams on how to best design their software to work on their infrastructure, the onus of publishing changes to said infrastructure or tools used to interact with it, ultimately falls on the platform team.
This model is fairly common amongst small and large companies alike. This team goes by many different names, such as the “Platform”, “Production” or “Infrastructure” engineering teams. Others typically call this the “DevOps” or “SRE” team. Regardless of the name, they usually share a few common attributes:
- Responsibility over scaling, architecture and maintenance of physical or virtual hardware on which the application sits, and,
- Responsibility over tools and services used to deploy software onto this infrastructure.
In Closing
From companies deploying everything to bare metal (there are plenty that still do, for good reasons) to trail blazers doing everything serverless, the practices and ideas behind DevOps are here to stay. The skill and tool surface area is large, and the manifestations can vary depending on the company. Regardless, the work is interesting, the results are impactful, and, most importantly, it gets teams tearing down walls and working together to make businesses faster and more responsive.It’s a wonderful thing to experience.
Theory Books
You might have heard of or read The Phoenix Project by Gene Kim. It covers much of the history I explained earlier (with much more color) and describes their journey to a lean company running on Agile and DevOps. It’s a great book.
Here are some others that are worth a read:
- Driving Technical Change by Terrance Ryan. Awesome little book on common personalities within most technology organizations and how to deal with them. This helped me out more than I expected.
- PeopleWare by Tom DeMarco and Tim Lister. A classic on managing engineering organizations. A bit dated, but still relevant.
- Time Management for System Administrators by Tom Limoncelli from Stack Overflow. While this is heavily geared towards sysadmins, it provides great insight into the life of a systems administrator at most large organizations. If you want to learn more about the war between sysadmins and developers, this book might explain more.
- The Lean Startup by Eric Ries. Describes how Eric’s 3D avatar company, IMVU, discovered how to work lean, fail fast and find profit faster. Lean Enterprise by Jez Humble and friends is an adaption of this book for the enterprise. Both are great reads and do a good job of explaining the business motivation behind DevOps.
- Infrastructure As Code by our very own Kief Morris. Awesome primer on, well, infrastructure as code! Does a great job of describing why it’s essential for any business to adopt this for their infrastructure.
- Site Reliability Engineering by Betsy Beyer, Chris Jones and others. A book explaining how Google does SRE, or also known as “DevOps before DevOps was a thing.” Provides interesting opinions on how to handle uptime, latency and keeping engineers happy.
Technical Books
If you’re looking for books that’ll take you straight to code, you’ve come to the right section.- TCP/IP Illustrated by the late W. Richard Stevens. This is the classic (and, arguably, complete) tome on the fundamental networking protocols, with special emphasis on TCP/IP. If you’ve heard of Layers 1, 2, 3 and 4 and are interested in learning more, you’ll need this book.
- UNIX and Linux System Administration Handbook by Ben Whaley and Evi Nemeth. A great primer into how Linux and UNIX works and how to navigate around them.
- Learn Windows Powershell In A Month of Lunches by Don Jones and Jeffrey Hicks. If you’re doing anything automated with Windows, you will need to learn how to use Powershell. This is the book that will help you do that. Don Jones is a well-known MVP in this space.
- Practically anything by James Turnbull. He puts out great technical primers on popular DevOps-related tools.
References
[1] https://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/
[2] http://www.full-stackagile.com/2016/02/14/team-organisation-squads-chapters-tribes-and-guilds/
[3] https://github.com/garystafford/voter-service
[4] https://github.com/maxamg/cd-office-hours
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
