
Simon Flühmann
Lead Consultant
«Microservices»: yet another buzzword you might think - but behind the term microservices lies an architectural pattern with great potential.
Author: Simon Flühmann
Microservices is an architectural approach to the design of highly scalable and robust applications to meet the increasing demands for agility, availability and maintainability of today's software systems. Large IT companies such as LinkedIn or Netflix have shaped this design approach. In contrast to classically monolithic applications, microservice environments are built from several small modules - the microservices. Each microservice independently takes care of a dedicated technical task (Single Responsibility Principle). Each Microservice works completely autonomously, can be developed autonomously and brought into production.
The following figure shows the schematic structure of a microservice architecture. The individual microservices together form an application. Each microservice encapsulates its own business logic including the corresponding database. The modules communicate with each other via APIs and/or a message broker. The application exposes interfaces via a portal for end customers or other consumers.
A critical point in the implementation of microservices is data management. The basic idea is a consistent encapsulation of the data with the business logic that operates on the data. Each microservice must manage its own data, which it needs to function autonomously. Specifically, each module should operate its own, completely independent data storage. Depending on the granularity and complexity of the architecture and the scope of the system, consistently following this pattern in practice can be a challenge.
To meet this challenge, there are different variations of approaches, which are discussed in this three-part blog series.
The CAP theorem should be consulted when choosing the appropriate model for implementing data management in a microservices architecture. CAP stands for:
The CAP theorem states that the three factors of consistency, accessibility and partition tolerance cannot be fully satisfied simultaneously in a distributed system. The focus can therefore only ever be placed on two of the three factors. The difficulty of cleverly prioritizing these factors is a constant companion.
The Failure Tolerance (P) factor should be met in any case, since latencies due to communication problems on a network occur frequently. A good solution is therefore a combination of Partition Tolerance and another factor. When designing the system, it should be evaluated very carefully whether a microservice should rather fulfil high availability (AP) or data consistency (CP).