It’s a bit controversial to say ‘Microservices are not simple’ given much is said about using Microservices to simplify and accelerate software delivery. So, how can this statement be made? It is a point actually stated in Chris Richardson’s excellent new book Microservice Patterns (avalable here and here), indirectly in Eric Evan’s Domain Driven Design (here). Martin Fowler in one his blogs says that they come at a premium (here). So, I’m not the first to say this, and wont be the last.

But the assertion that Microservices done right are simpler, and allow rapid delivery and evolution of solutions – a bit of a contradiction. As they say a picture is worth a thousand words, so take a look at this …

To make a change with the monolith and understand what the impact of the change is you can it needs to have far greater appreciation of how the entire solution works (area highlighted in gray). It changes are implemented without the full understanding and adherence of the design strategies, patterns etc, or more commonly changes rushed in to address some urgent need (business deadline, bug and so on) the design is eroded and it the effort to understand the change impact accelerates. Net result, the monolith becomes difficult and unwieldy despite the best intentions.

Microservices are inherently more complex because they need need to accommodate the possibility of being distributed they share less, therefore need a bit more foundation.  So now not only do you need to understand the programming language, and a simple app container such as Tomcat but also Docker and something like Kubernetes or Istio. But, and this important thing is that the isolation between the different services is more robust – no longer can you just add another import, add 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.

The second thing, is that to understand anyone part of a solution requires less understanding of the whole, net result we are likely be able to see and understand the area we are concerned with and presented with less temptation to use shortcuts to deliver those urgent solutions that are always needed.

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. The difference is though is in the monolith world the platform specialist doesn’t have to struggle with the big picture whilst tuning resources – i.e. some parts of a monolith may be memory hungry others may need I/O performance. In the microservice world the Kubernetes specialist need only master one set of dependencies at a time to optimise the deployment and deliver value. Not only that, there is the chance that different microservices will have related demands so can share infrastructure most suited to those demands, and host the microservices with different demands on infrastructure meeting its needs.

Coming back to our original statement, there are moving parts – thus complexity, but it is easier to master any one part because it is smaller. Not only that as the solution grows, the more effective it becomes as the point at which it becomers possible to have specailists for each component and layer.  Whilst Martin Fowler’s diagram (below) doesn’t show this, I suspect it will hold true.