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. Consequently, both the company culture and team culture need to be considered when picking the right topology.
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.
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
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.
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.
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.
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.