Picking a DevOps Topology

For each individual product or project that a company has, there will be an individual team associated with it. That team will need to choose their own devops topology, taking into consideration that Culture Influences Infrastructure. Consequently, both the company culture and team culture need to be considered when picking the right topology.

DevOps Topology Type 1: Dev and Ops Collaboration

Dev and Ops must have a clearly expressed and demonstrably effective shared goal (‘Delivering Reliable, Frequent Changes’, or whatever).

Ops folks must be comfortable pairing with Devs and get to grips with test-driven coding and Git, and Devs must take operational features seriously and seek out Ops people for input into logging implementations, and so on.

DevOps Topology Type 2: Fully Shared Ops Responsibilities

Organisations such as Netflix and Facebook with effectively a single web-based product have achieved this Type 2 topology, but I think it’s probably not hugely applicable outside a narrow product focus

DevOps Topology Type 3: Ops as Infrastructure-as-a-Service

Treats Operations as a team who simply provides the elastic infrastructure on which applications are deployed and run

A team (perhaps a virtual team) within Dev then acts as a source of expertise about operational features, metrics, monitoring, server provisioning, etc., and probably does most of the communication with the IaaS team.

Organisations with several different products and services, with a traditional Ops department, or whose applications run entirely in the public cloud.

DevOps Topology Type 6: DevOps Advocacy Team

Organisations with a tendency for Dev and Ops to drift apart.

The DevOps team exists on an ongoing basis with the specific remit of facilitating collaboration and cooperation between Dev and Ops teams. Members of this team are sometimes called ‘DevOps Advocates’, because they help to spread awareness of DevOps practices.

DevOps Topology Type 7: SRE Team (Google Model)

Has a team (SRE) in charge of determining criteria of release quality and code maintanence in exchange for handling release + support.

Collaboration between Dev and SRE happens around operational criteria; SRE supports in production.

DevOps Topology Type 8: Container-Driven Collaboration

The container acts as a boundary on the responsibilities of both Dev and Ops

Works well with a sound engineering culture. Requires devs to write good containers and not ignore operational concerns.