Architecture pattern Microservices

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.

Features of a microservices architecture

• Autonomy: Microservices function independently. This applies to the runtime as well as to development and deployment. Each microservice can be developed and rolled out independently. The modules are also technologically independent of each other - each microservice implements its own technology stack. This also applies to data storage. The result is a system with polyglot persistence in which the modules do not share data storage.
• Decoupling: Microservices are strongly decoupled from each other. They communicate only via clearly defined and language-independent interfaces. Decoupling takes place at all levels (data storage, security, technology, architecture, deployment, etc.). Modules can be easily exchanged and replaced by this decoupling.
• Automation: Microservices enable a high degree of automation for deployment, testing, provisioning and scaling. In connection with continuous delivery, releases can be set up independently and quickly for production thanks to a microservice architecture. Thanks to minimal time-to-market, it is possible to react quickly to changes and trends.
• Scalability: Microservices are built to scale a system quickly and easily. Due to the decoupling, the modules can be deployed independently. New instances can be dynamically raised and then lowered again as required.
• Resilience: In case of partial failures and errors, the system can continue to function. Due to the decoupling and isolation of the modules, errors and latencies only have a local effect and do not necessarily lead to a breakdown of the entire application. The components have the ability to regenerate themselves. Through decoupling, combined with scalability and replication, high availability scenarios can be effectively implemented in a microservices architecture.
• Security: The encapsulation facilitates the protection of the individual modules. Isolated microservices can be protected separately with firewalls and gateways.
• Business Value: Increased efficiency in development, savings in operation, stability leads to a good customer experience and fewer failures. The system grows and shrinks dynamically with customer demand, new features are on the market in the shortest possible time, improved testability reduces the risk of releases.
• Organisational aspects: A prerequisite for the successful implementation of a microservices architecture is also the appropriate organizational structure. An established DevOps culture with product-oriented, agile teams is an important prerequisite for the successful development of microservice applications. Further information and support on the topic of DevOps transformation can be obtained from our DevOps experts.

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.

The challenge of data management for microservices

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.

CAP Theorem

The CAP theorem should be consulted when choosing the appropriate model for implementing data management in a microservices architecture. CAP stands for:

• Consistency: Overall consistency of data throughout the software system after the completion of a transaction.
• Availability: All queries to the system are answered in any case. Partition
• Tolerance: Continued functioning of the system in case of data failure.

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).