Microservices architecture - hype or new reality?

Microservices promise to make IT fit for the future! But what does it take? And where does its use make sense? Answers in the article.

Author: Matthias Hert

Which characteristics describe a microservices architecture? And what basic concepts must be in place to build a functioning microservices architecture?

Microservices is an architectural style for the creation of applications. It follows the approach of building complex applications modularly, based on fine-grained building blocks, the so-called microservices. The functionality of the individual microservices is made available to other microservices and clients via APIs or Message/Event Bus. Each microservice functions autonomously and implements a very specific function. This corresponds to the philosophy known from the Unix environment «do one thing, and do it well», i.e. perform only one function, but do it well.

The following figure shows the schematic structure of a microservices architecture.

Microservices-Architektur.png
Schematic structure of a microservices architecture

Features of a microservices architecture

  • Autonomous: Microservices function independently. This applies to the runtime as well as to development and deployment. Each microservice can be developed and rolled out independently.
  • Decoupled: Microservices are strongly decoupled from each other. They communicate only via clearly defined and language-independent interfaces. For synchronous calls these are APIs and for asynchronous communication a Message/Event Bus is used.
  • Scalability: Microservices can be scaled independently and as required.
  • Resilient: Microservices are fail-safe and fault-tolerant. Errors only affect locally and do not spread throughout the entire system. The concept of a bulkhead known from shipbuilding is implemented. An availability of 100% is thus possible.

Basic concepts of a functioning microservices architecture

  • Continuous Delivery: High degree of automation for provisioning, scaling, deployments and regression testing. Allows individual microservices to be rolled out independently and securely.
  • DevOps: Fast development and secure operation can only be achieved if development and operation work together. The organizational structure of a company is also reflected in the design of its systems (see Conway's Law).
  • Central basic services: Common functions such as logging, monitoring and configuration should be provided centrally for all microservices. This simplifies operation and accelerates development.
  • API Management: Decouples the client from the individual microservices. Enables the composition of the fine-grained microservices into coarse-grained, client-oriented services. Security is another aspect that can be solved centrally via an API gateway.
  • Domain Driven Design: The appropriate division of the domain into individual microservices is of central importance for a functioning microservices architecture. Domain Driven Design provides the necessary tools for this.

When does it make sense to use a microservices architecture?

Microservices architectures are primarily suitable for building applications that differentiate a company. These applications are often subject to constant change and must be adapted quickly due to market changes. Concrete examples would be the online shop of a retailer, the customer portal of an insurance company or the e-banking of a bank. But are the requirements regarding scalability and flexibility of the applications really that high? The choice of a microservices architecture must be well considered! After all, the flipside of microservices architectures is the considerably increased complexity, as well as the necessary organizational changes in the direction of cross-functional teams. In addition, DevOps and Continuous Delivery are concepts that must be implemented first. Only then can a microservices architecture lead to success.

Even if microservices are currently a hype, in many cases a conventional application architecture with considerably less complexity is sufficient.