Microservices folgen einem der wichtigsten Paradigmen bei der Entwicklung von Software: der modularen Programmierung. Dabei wird das Computerprogramm in logische Teilblöcke, die sogenannten Module, aufgeteilt. Dadurch können auch größere Softwareprojekte besser organisiert, umgesetzt und verwaltet werden.

Um dieses Paradigma zu erfüllen, gibt es jede Menge Ansätze und Lösungen. Darunter zum Beispiel der Einsatz von Klassen, die wiederum in Pakete zusammengefasst werden. Um allerdings ein solches Konstrukt ausführen zu können, müssen immer alle Pakete und Klassen deployed werden.

Microservices haben genau in diesem Punkt einen entscheidenden Vorteil: Sie können auch unabhängig voneinander eingesetzt werden. Soll also das System um einen Microservice erweitert werden, so muss lediglich dieser eine Service in Produktion gebracht werden anstatt aller Services.

Microservices kümmern sich jeweils unabhängig voneinander um eigene kleine Teilaufgaben und sind nach außen hin isoliert. Um die Kommunikation zwischen den Microservices zu ermöglichen, werden standardisierte Schnittstellen wie zum Beispiel REST eingesetzt.

Dabei laufen die verschiedenen Microservices, die ein Gesamtsystem ausmachen, auf getrennten Servern oder auch virtuellen Maschinen. Würden alle Services auf einem einzigen System laufen und ein Microservice das System überlasten, so bestünde die Gefahr des Ausfalls der anderen Services auf dem System. Diese Gefahr wird dadurch minimiert, erhöht allerdings die Komplexität des Systems.

Die Unabhängigkeit eines Microservices von anderen ermöglicht das ebenso unabhängige Arbeiten kleiner Entwicklerteams, die einen oder mehrere thematisch zusammengehörige Microservices verwalten. Dabei ermöglicht die vorhandene Isolation der Services die Entwicklung eines Microservices in einer beliebigen Programmiersprache und auch mit verschiedenen Technologien. Es muss lediglich der Standard der verwendeten Schnittstelle eingehalten werden. Selbst das komplette Ersetzen eines Microservices lässt sich dadurch denkbar unkompliziert umsetzen.

Dabei besitzt eine Microservice-Architektur auch eine hohe Stabilität. Durch die Unabhängigkeit der Microservices läuft das System weiterhin, selbst wenn ein Service ausfällt. Der Fehler muss dann lediglich im entsprechenden Microservice behoben oder durch einen neuen Service ersetzt werden, während die restliche Architektur davon unberührt bleibt.

Auch lässt sich eine derartige Anwendung ohne Probleme vergrößern oder verkleinern. Dabei werden lediglich die einzelnen Microservices unabhängig und je nach Bedarf individuell skaliert.

Kein Architektur-Ansatz kommt ohne Nachteile aus. So auch Microservices. Die große Anzahl der verteilten kleinen Services erhöht die Latenzzeit immens, da die Kommunikation zwischen den Microservices über verschiedene Server hinweg läuft anstatt nur zwischen Prozessen auf einem einzigen System.

Während Microservices das Programmierparadigma der Modularität perfekt erfüllen, wird ein anderes verletzt. Das Prinzip „Don’t repeat yourself“ (Wiederhole dich nicht) soll redundanten Code in einem Projekt vermeiden. Dabei werden Codeabschnitte – wenn möglich – an mehreren Stellen wiederverwendet. Durch die Unabhängigkeit der Teams bei der Entwicklung von Microservices besteht genau dabei die Gefahr, dieses Prinzip zu verletzen. Auch wenn Microservices verschiedene Aufgaben behandeln, können sie trotzdem ein gleiches Problem aufweisen. Wurde dieses bereits durch ein Team innerhalb eines Services gelöst, so muss es durch die Isolation der Microservices in dem anderen Team erneut umgesetzt werden.

Insgesamt erhöht die Unabhängigkeit und die Isolation der Microservices an mehreren Stellen den Aufwand. Darunter wird das Testen der Software komplexer. Auch der Vorteil des unabhängigen Deployments wird zu einem Nachteil, da jeder Microservice seinen eigenen Deployment-Prozess benötigt.

Vor Projektbeginn sollten alle Aspekte genau abgewogen werden, bevor sich ein Team für oder gegen eine Microservices-Architektur entscheidet. Microservices haben vor allem bei größeren Projekten entscheidende Vorteile: unabhängige kleine Teams sowie die Skalier- und Wartbarkeit und die Tatsache, dass nur eine geringe Koordination zwischen diesen Teams notwendig ist, sind nur einige davon. Die Frage ist jedoch, ob diese Vorteile schwerer wiegen als der in vielerlei Hinsicht größere Aufwand.