Why microservices and monoliths are not simple

Publish date:

Microservices are inherently more complex because they are distributed and shared less, and therefore, require a better foundation.

It’s a bit controversial to say that microservices are not simple given how much is said about using them to simplify and accelerate software delivery. So can this statement even be made? It is, in Chris Richardson’s excellent new book, “Microservice Patterns” (here) and indirectly in Eric Evan’s “Domain-Driven Design” (here). Martin Fowler also agrees that they come at a premium in one of his blogs (here).  So, I’m not the first to say it, and I won’t be the last.

But the assertion that microservices done right are simpler and allow rapid delivery and evolution of solutions is a bit of a contradiction. Since a picture is worth a thousand words, take a look at this:


To make a change with the monolith and understand the impact of the change, you need to have a greater appreciation of how the entire solution works (area highlighted in gray). If changes are implemented without understanding or adhering to the design strategies and patterns, or if changes are rushed to address some urgent need (business deadline, bug, and so on), the design erodes and the effort to understand the change impact for future changes is accelerated. In effect, the monolith becomes difficult and unwieldy.

Microservices are inherently more complex because they are distributed and shared less, and therefore, require a better foundation. So, not only do you need to understand the programming language, and a simple app container, such as Tomcat; you also need Docker and something like Kubernetes or Istio. It is important that the isolation between the different services be more robust; no longer can you just add another import or another method overload on class. It takes more effort and it is easier to govern the points of exposure. As a result, the risk of design degradation is reduced – but not removed.

Moreover, understanding any one part of a solution requires less understanding of the whole. The net result is that there is less temptation to use shortcuts to deliver urgent solutions for just one area. Regardless of whether the solution is a monolith or microservices, sooner or later the solution will reach a point where dedicated skills in those non-functional areas are needed. But in the monolith world, the platform specialist doesn’t have to struggle with the big picture while tuning resources – i.e., some parts of a monolith may be memory-hungry while others need I/O performance. In the microservices world, the Kubernetes specialist only needs to master one set of dependencies at a time in order to optimize deployment and deliver value. Furthermore, there is the possibility that different microservices will have related demands – so they can share infrastructure most suited to those demands and host the microservices with different demands on infrastructure meeting its needs.

Which brings us back to our original statement: since there are moving parts, there is complexity, but it is easier to master any one part because it is smaller. As the solution grows and becomes more effective, it becomes possible to have specialists for each component and layer. While Martin Fowler’s diagram (below) doesn’t show this, I suspect it holds true.


The author will be at Oracle Code London in May 2018 and will be presenting on the topic “Microservices in a Monolith World.” You can connect with the author online or register for the event here

Reference: Microservice Premium from Martin Fowler

Related Posts


Cloud-first, API-first, or legacy modernization: Finding the right roadmap

Akshay Kumar
Date icon April 3, 2019

Whether you call it a truism or a cliché, one of the maxims of travel is that the journey is...


APIs: the tools turning every company into a tech company (yes, yours too)

Cliff Evans
Date icon January 7, 2019

Buying a movie ticket today is a straightforward business; all it takes is a few clicks to...


API-fication: a three-step process to joining the API economy

Al Liubinskas
Date icon November 9, 2018

API-fication is a tool that new economy leaders are using to grow revenue 5% faster, create...


By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.


Close cookie information