Microservices as a team-centered concept

In a previous article, an introduction microservices architecture was given and pros and cons over other architectures were provided. Focusing on how to organize microservices around development teams, you can see some of the company structure mirrored in it. As Conway's Law states:

Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation's communication structure.

The quote conveys that there's a link between system design and organisational structure. In this article, I'll show how microservices architecture work together with a team oriented concept.

Exploring the team structure

With a microservices architecture, a team may own one or more microservices. With that in mind, what's the right team structure, both in terms of size and composition?

Team size concerns

In regards to size, Amazon suggests a two-pizza team, striking a balance between collaboration (the smaller the team, the more tight knit it is), communication delays (communication inside team is quick, while inter-team is slow) and domain knowledge.

What if the company only has one development team of four people? At this size, it's hard to justify the maintenance overhead that comes with a microservices architecture. Remember that microservices expect isolation, isolated continuous deployment and continuous integration, APIs and so on. Consider keeping a monolith instead, and enforce strong decoupling design patterns in the code, so that, if the need arises to migrate to microservices, that migration is smoother.

How to compose a team?

When it comes to team composition, following the two-pizza team approach while considering the microservices architecture, a team needs to be well rounded. Since teams are expected to have single ownership of services, there needs to be skill and expertise from beginning to end of the process. In essence, this means a team must be cross-functional, having knowledge in customer communication (customers here include other internal teams), software development, infrastructure, system administration, operations, QA. With this paradigm shift certain job titles that used to be a lot less common with the monolith architecture started to appear: Full Stack Developers, DevOps Engineers, to name a few. A potential side effect is that team members that enjoy certain development areas, such as UI/UX, may need to work on other parts of the microservices, which may alienate them, making them feel less useful or productive.

Team interaction with microservices architecture

When different teams own microservices that interact, eventually there will be features that force the actual teams to also interact. This can be a small request, such as needing a new endpoint to get more data from a service, or a much larger project that spans changes in multiple microservices, where teams need to organize their work and milestones as a joint effort.

Communication as signal to the right architecture

The amount of times inter-team interaction happens may inform how well your microservices architecture is designed. If anytime a microservice changes, the team needs to request changes to another team, that means those microservices are tightly coupled. In those situations, a few outcomes are possible:

Reorganise teams, so that those changes happen within one team in the future. This may require shuffling employees around, which is not ideal.

Refactor microservices, if possible extracting the service or part of service that provokes this unwanted interaction. This creates the least amount of churn, but is not always possible.

Leave it as is, and live with the communication effort and time overhead. If the interactions have low frequency, this can be the best choice.

Team oriented leadership

Having teams working as independent units, as owner of their destiny, can be a hard pill to swallow for company leadership. Being able to accept that you'll have a looser management style is as much part of the microservices architecture success as choosing the right tools. Trust that team members want the best for their services, and in turn, the full product.

Conclusion

Working as a team focused on a specific domain, independent, with minimal external influence is a surefire way of keeping a development team happy and increase talent retention. Microservices help with this culture by making sure the domains are isolated and owned by expert teams on their own.