Microservices Will Mess Your Team Up
Microservices are popular with many teams. But, software development patterns are still in flux around this architectural pattern. In the last several years the space has matured a lot. Still, too many teams produce poor implementations.
Microservices are often placed in contrast to Monolithic applications. That comparison is instructive, but it is also naive. Microservices is an extension of modular, or component-based, software design. It applies the idea of boundary definitions and extends it towards clearer vertical segmentation.
The problem I’ve observed is that very few teams invest the requisite time to define proper boundaries. That failure produces difficult to maintain applications when it comes to Monolithic applications. Microservice systems that lack such defined boundaries are an order of magnitude worse. Without defined boundaries in a Microservice ecosystem, all you end up with is a distributed Monolith. This reality is one only experienced teams seem to appreciate.
Counting the Cost
Independent and granular deployability is the biggest benefit that many teams do not need. This benefit comes at the cost of operational complexity for a distributed system. From messaging protocols, to event and message channels, to coordination and discovery. Even small ecosystems need more complex tooling requiring specialized operations-oriented knowledge and skills.
Another big benefit of Microservices is stronger module boundaries. But, too many teams have difficulty defining boundaries in a Monolithic applications. That difficulty is not reduced with an architectural approach as complex as Microservices. Teams that adopt Microservices need architectural skill in identifying and defining boundaries. That skill is easier to hone in a Monolithic application first, but few teams invest in that approach.
Without defined boundaries in a Microservice ecosystem, all you end up with is a distributed Monolith.
Technological diversity is something that can keep a team excited about their work. Microservices make it easier to adopt diverse technologies. Like independent deployability this benefit comes at the expense of operational complexity. And, teams can adopt more technologies than they can manage if guidance is lacking.
Solve Your Problems
Microservices, like any architectural approach solve certain problems and opens doors to others. Before adopting any approach it is important to identify the needs of a project and team. In more cases than not, Microservices are the wrong place to start. Until a team needs independent deployability and has the skill to identify and sustain clear service boundaries a Monolith is best. Too many teams pursue Microservices for the wrong reasons and fail to identify the problems they want to solve.
Make a Map
One approach that any team can borrow from Domain-Driven Design is to work on a Context Map. A Context Map defines the various Bounded Contexts that exist within a system. It is technology and implementation independent. This practice can help a team gain insight on where boundaries should exist in their system. It can also help them explore how those boundaries may overlap or need to interact. This kind of team and business discovery will help identify where Microservices may present real value.
Conway’s Law is often cited in relation to Software Architecture and it is a valuable concept to keep in mind. But, the influence of an organization on the systems it produces is not one-way. The systems a team works on will also influence the organization. Teams that work on distributed systems can also tend towards separation and lower cohesion. Without specific practices to manage these tendencies teams can become insular and territorial. So, adopting Microservices is as much about culture as it is about technology. And, if that is not taken into account the choice of Microservices may harm, rather than help, your team.
