The socio-technical aspects of microservices: ownership
This article is part of the series “the socio-technical aspects of microservices”.
Today we will discuss one of the most important aspects of microservices: ownership. More specifically, we will explore why each microservice should have exactly one owner and why those owners should always be backed by teams.
Stick to this rule and it becomes more likely that microservices will help you to achieve your goals. Ignore it, and microservices will become a huge liability.
This article is part of a series on the socio-technical aspects of microservices. I would claim that service ownership is the foundation for everything else we are going to discuss, which is why we will cover it first.
What’s a service owner anyway?
When you take on the role of a service owner, you will be given new responsibilities, but also new privileges.
As a service owner, you must …
- keep the service running reliably
- ensure the service hits its SLOs
- respond to all incidents and conduct post-incident reviews
- maintain good relationships with your service’s consumers and providers
As a service owner, you may …
- release the service as often as you like
- make all the design decisions
- decide how exactly the service is going to change
- contribute to the design of the entire system
Ideally, responsibilities and privileges balance each other out. The responsibilities make your job more difficult, while the privileges make it easier.
Services should be owned by teams
When we talk about ownership, we traditionally think about individuals. When it comes to service ownership, however, we should think about teams instead.
Although it is true that ultimately all responsibility and decision power rests within the organization’s managers, those managers are backed by teams. A wise manager shares the service owner role with his entire team.
This is because sharing both, the responsibilities and the privileges, is beneficial.
When an entire team is responsible for a service, it becomes possible for individuals to take time off work or even to leave permanently. No longer does a single person have to be on-call 24⁄7. This might seem obvious for you, but I’ve worked in startups where the only person on-call was the technical founder. Those arrangements never seemed sustainable. It’s more feasible to rotate the on-call duty between team members.
Likewise, yielding most decision power to the entire team means that many decisions have to be made through consensus.
This is a good thing. A lot can go wrong when we change our production services. Even a small mistake could lead to partial or total failure. By making design decisions as a group, we can bring in new perspectives and benefit from additional expertise. This, in turn, helps us to make better decisions.
Service ownership should be clear
I’ve once worked for a company where everyone was supposed to be responsible for all the microservices of everyone else.
Instead of following the “you build it, you run it” paradigm, we practiced “someone builds it, you run it all”. A group of 50 developers was responsible for 15 microservices. There was a single on-call roaster for all of the services and when it was your turn, you were responsible for all of them. Of course it was almost impossible to so something useful when an actual incident occurred.
Although in theory everyone was responsible for everything, in practice no one was responsible for anything.
This had another interesting effect. To get their projects over the line, teams often had to make changes to several services. And since no one owned the services directly, no one took a stand for the maintainability of each microservice. As a result, the quality of the entire system degraded over time.
This experience convinced me that each service should be associated with a single team.
I found that teams behave differently when they feel responsible for a microservice. They start to care more about the reliability and the maintainability of the service. If they feel empowered to make changes as they see fit, they often begin to make improvements. Over time, this can really make a difference.
This wraps up our discussion of microservice ownership. In the next article, we will briefly talk about why we would choose a microservices architecture.