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.
Top comments (4)
Hey James, great post! I hope to take some of these tips on board with my current project. You mentioned that "Without specific practices to manage these tendencies teams can become insular and territorial". I have seen these issues first hand even within a single team (one person will build a service then they are shackled to that for life) do you have any suggestions of specific practices people could follow to help avoid these issues? Simply doing cross bounded context MRs? or are there some other tricks of the trade to use?
I am a big fan of Extreme Programming and think some of the practices that come out of that can be really helpful. Specifically I would look at pair programming and team rotations. Team rotations gets more tricky as a team gets larger and if technology diversifies. That would be my most immediate thought for how to counteract the negative effects that microservices can introduce.
I agree, I can see in our own projects, a lot of time is spent in redefining the need, again and again. Not that is should be perfect from the start, but sometimes critical business decisions are taken after 2 weeks of development, and this greatly reduce our performance.
So I would say definitively, teams needs to sit down and think first. And also, not hesitate to draw, to make schemes, write a lot of use cases...
Boasting a heritage of distinction over an extended period, our renown stands as proof of our resolute dedication to delivering top-tier garage door repair services in Yorktown, VA, and its surrounding locales. As Fixing Garage Door Problems your reliable ally, we offer an unwavering assurance to swiftly address your requirements, ensuring the resolution of your garage door concerns with effectiveness and attentiveness.