Which DevOps topology is right for me?
Why should I read this?
You’re working in an organisation that aims to explore the benefits of working according to DevOps principles. You’ve heard terms like “platform team” and “SRE” and you have an idea what “you build, you run it” means. These terms, however, have made your exploration into DevOps more complicated and now you even have to choose how to organise your team(s). This blog provides an overview of the three most applied DevOps topologies and which conditions make a specific topology a good fit for your company.
As a reference, Matthew Skelton’s “DevOps topologies” (http://web.devopstopologies.com/) page gives a nice overview of all kinds of organisational topologies. These topologies have been implemented by companies around the world in their quest for agility and operational excellence through DevOps. Although many topologies have been documented, I believe that they are all variants of these three topologies:
1. All teams are product teams. Each team does everything that is needed to run their software including the use of any infrastructure components, usually cloud-based PaaS.
2. Internal platform team(s) and Product team(s). Product-teams make use of the infrastructure/platform-services provided by internal platform-team(s). Services provided by the platform-team(s) can range from infrastructure and “run” services such as monitoring to Continuous Integration tools and dashboarding tools.
3. Internal Platform team(s), Product team(s) and Site Reliability Engineering team(s) (SRE). This topology is based on Google’s best practices around running software. Product teams can gain the SRE teams’ support in running their software if they need it and if their software adheres to standards defined by SRE teams. SRE teams can also share on-call responsibility with product teams. The platform-team(s) provide infrastructure/platform-services.
The DevOps topology that will have the best fit within your organisation is dependent on your current organisational hierarchy, scale, regulatory requirements and people’s skills. It is also important to recognise that any chosen topology has its pitfalls, which need to be dealt with.