The hype cycle, or Microservices as Logical Physical Confusion

The tech industry is subjected to hypes, or manias. Maybe even more than other fields. As evidence for that one can list the number of silver bullets that emerge every 5 years or so.

I myself believed in some silver bullets. I remember vividly how I thought that using scaffolding in Rails made me better than a team of Java devs. I suppose that these days some Node.js guy thinks the same about the Rails guys, or some other combination that I’m not aware of.

The case I bring in this article is that of microservices. Microservices are sold as an alternative to monoliths that are not modular enough. The argument is usually mixed with points about deployment being faster and (the usual magic words) agile and dynamic. The point of view I take in this article is that this argument is fundamentally confused and wrong, in that it sells a physical solution to a logical problem.

This point of view is that the microservice architecture is a confusion of logical and physical concerns. The logical concern is modularization, expressed more precisely in terms of information hiding:

Information Hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed. The protection involves providing a stable interface which protects the remainder of the program from the implementation (whose details that are most likely to change).

Information hiding is a pure logical concern, and can be expressed in any language/architecture, from Assembly all the way to Haskell.

One physical concern is scalability, which can be achieved using multiple tools (processes, kernel threads, user threads, and fibers). What to use depends on the tools, the production platforms and the usage profile of the application. It is a decision that should usually be taken after measurement (premature optimization is the root of a lot of problems, so the saying goes).

Another physical concern being conflated is deployability, more specifically the activities involved with providing updates to production software. This also depends on the tools, production platforms and the usage profile of the application.

My hope in writing this piece is twofold:

1. Show the value of unpacking the meaning of terms (microservices). Doing that can help one focus his efforts and the actual problem using the correct domain (logical vs physical, in this case).
2. Help programmers be more aware of hype cycles and avoid silver bullet mentality.