Microservices in a historical perspective

A hype like microservices seems to come out of the blue. In this blog I’ll argues that this is not the case: a number of paradigm shifts form the basis for the evolution from traditional service orientation into microservices. In a series of blogs I’ll place microservices in a historical perspective and explain why the hype was able to grow to its current state. In this blog I will, staccato, give an overview of these developments; in the next blogs I will dig deeper, topic by topic.

Microservices, as a software “[…] architectural style is an approach to developing a single application as a suite of small services, each running in its own process and using lightweight mechanisms for communication, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may each be written in different programming languages and use different data storage technologies.“

In comparison to other styles, microservices are often compared to “monoliths”. I prefer to compare it to Service Orientation (hereafter SOA): it is mainly a reaction to the lessons we have learned. In essence, in my opinion, it is a classic shift from centralization to decentralization: where SOA requires a strong central coordination, microservices promote a strong decentralization.

Since the emergence of SOA, a number of paradigms have shifted:

worldview: the realization that the world is a complex composition of different worldviews; Domain Driven Design teaches us about “bounded contexts”, and that semantics inside a certain context are not usable beyond that context;

reuse: reuse was primarily meant to reduce costs and to achieve consistency in your data; in both aspects, reuse has not lived up to its potential. Especially reuse across “bounded contexts” is a bad idea, which introduces lots of unnecessary complexity;

consistency: ACID is a mantra from transaction-based software that is difficult to reconcile with asynchronous communication, a core concept of microservices; by letting go of permanent (in exchange for eventual) consistency, new opportunities arise;

finite resources: Moore’s Law, the observation that the number of transistors in a dense integrated circuit doubles approximately every two years, is still valid; everything is faster and larger (internal memory for example), so there is less need to be “efficient”;

turnaround times: there are still some organizations that release a few times a year, but they are rare; multiple releases per day will become the norm;

These paradigm shifts are supported by shifting views of development of information systems, that need to be taken into account:

DDD, Domain Driven Design: breaking down the problem domain into subdomains, each with its own semantics; between subdomains, information must be carefully “translated” to avoid confusion;

ES, Event Sourcing: decoupling based on a “publish-subscribe” mechanism, in which the “world” is defined by the events that occur;

technological enablers: the cloud, container technology, automated testing and deployments, all developments that support the shift to decentralization.

A warning is justified, before declaring microservices to be a holy grail: as with any shift to decentralization, chaos is lurking. There are some risks that need to be mitigated carefully:

governance: to keep track of all those services, extensive automation and “failure isolation” are required; the failure of one service may never disseminate to other services;

consistency: letting go of ACID transactions must be guarded (among other things) in the context of the user experience; it is not permissible that a user updates his address and is confronted with the old address in the next screen …

decentralization is not only a technological and informational perspective, but also (and especially) an organizational one;

logging and audit trails: by the increased complexity at the central level, a good coordination of logging and audit trails is required.

In my next blogs I will elaborate on each topic and give more insights in its relationship to microservices.