I have always enjoyed utilizing the DevOps topologies website. Its simple explanations of the various patterns and anti-patterns common in the industry is a great starting point for discussions. However it left me struggling to have deeper, more concrete discussions. Over the last few years, I have started to adapt some language common in the vernacular of our cloud overlords the "Shared Responsibility Models".
Shared responsibility models give a clear and easy visual understanding of who is responsible for specific layers of an application stack. AWS does a great write up on this and shows off how different types of infrastructure services will impact who is responsible for particular layers. Check it out here. These visuals have been immensely useful when discussing the benefits (and downsides) of using cloud managed services with customers.
By making our own version of the application stack, we can similarly delineate which teams may be responsible for certain layers.
Having a visual aid like these, can make having conversations much easier. Displaying your production environment as a series of layers built on top of each other, shows off the reality of how we build cloud services today. It can also help discuss individual functions and responsibilities.
Does your engineering team own the application configuration in production or is that the responsibility of the operations team? How about ensuring the customer data doesn't get corrupted or deleted?
Typically when I use such models to discuss responsibilities, one inevitable question will arise, "What does having responsibility for a layer even mean?". It means that a team has full ownership and authority over all aspects of that layer. They can decide how to build, run and monitor it etc. It also means taking on-call duties for any alerts or incidents related to that layer.
If an engineering team is responsible for building your application, but does not take the on-call duties, it can be said that they have a shared responsibility with the operations team. Those two teams will then need to decide how to manage that relationship for that layer specifically. The higher up the stack, the more difficult it will become for an operations team to effectively remediate production issues without assistance from the teams that built it. Conversely, the lower down an engineering team moves down the stack, the further they move away from spending time developing your product.
To take the concept a little further, you can take the idea and look at the whole development pipeline. Mapping out who is responsible for various aspects along the pipe from development environment, through CI/CD and testing environments to production.
Having discussions about responsibilities can be difficult. Next time you are having conversations take the time to map them out using a shared responsibility model to break down the conversation into smaller conversational units.
The examples I have used in this post are overly basic to show off the concept. In reality these models are often more complex and specific to a companies particular setup.
Top comments (0)