Microservices Nonsense

Microservice Architecture (MSA) is a software design approach in which applications are intentionally broken up into remoteable services, in order built from small and independently deployable application building blocks with the goal of reducing deployment operations and dependency management complexity.

(See also Fowler, Thoughtworks)

Back in control

Sounds good, right? Anybody developing applications of some size knows that increasing complexity leads to harder to manage updates, increased deployment and restart durations, more painful distribution of deployables. In particular library dependencies have the tendency to get out of control and version graphs tend to become unmanageable.

So, why not break things up into smaller pieces and gain back control?

This post is on why that is typically the wrong conclusion and why Microservice Architecture is a misleading idea.

Conjunction Fallacy

From a positive angle one might say that MSA is a harmless case of a conjunction fallacy: Because the clear cut, that sounds more specific as a solution approach, makes it more plausible (see the Linda Problem of ….).

If you cannot handle it here, why do you think you can handle it here?

If you cannot organize your design to manage complexity in-process however, why should things work out more smoothly, if you move to a distributed setup where aspects like security, transaction boundaries, interface compatibility, and modifiability are substantially harder to manage (see also Distributed big ball of… )

No question, there can be good reasons for distributed architectures: Organization, load distribution, legacy systems, different expertise and technology preferences.

It’s just the platform (and a little bit of discipline)

Do size of deployables and dependency management complexity belong into that list?

No. The former simply implies that your technology choice has a poor roll-out model. In particular Java EE implementations are notoriously bad at handling large code bases (unlike, you might have guessed, z2). Similarly, loss of control over dependencies shows a lack of dependency discipline and, more often, a brutal lack of modularization effort and capabilities (see also Modularization is….)

Use the right tool

Now these problems might lead to an MSA approach out of desperation. But one should at least be aware that this is platform short-coming and not a logical implication of functional complexity.

If you were asked to move a piece of furniture you would probably use your car. If you were asked to move ten pieces of furniture, you would not look for ten cars – you would get a truck.



3 thoughts on “Microservices Nonsense

  1. In principle your arguments are solid and I share this line of thinking. There are however some (surprising for me) effects that I would fully attribute to our human nature.

    Going for microservices and ending up with average SOA is still a huge win for many companies. As often happens, organizations go for the “Marlboro man” moonshot only to end up losing their beer belly and that’s great win.

    Microservices are win in this way as they enforce the laying of the module/component boundaries. “Enforce” is the right word here. As you note it’s all matter of discipline and that’s precisely one of the top 3 root causes for bad decision making and designs in my experience. Microservices are the alternative to avoiding late night junk food binge by not buying junk during the day (and living in AT where no shop is open in the night).


    • Hey! Thanks for stopping by. There is scenarios where remote separation of services make sense – of course. And organizational responsibility splits can be one of them. It’s that “oh I am in deep shit with my complexity – let’s fix it by adding some more”-ignorance of the followers that makes me slightly angry (if I care enough).

      Another way of enforcing module boundaries before going remote is to have dedicated API modules and a reference regiment that enforces those. Makes the review set much smaller. Again, “enforcing” is the tricky business here.


  2. Pingback: Not with the target audience anymore? | ztheworld

Comments are closed.