Nanoservices – kleiner als Microservices

Inhaltsverzeichnis

Microservices lassen sich von getrennten Teams ohne größeren Kommunikations-Overhead entwickeln. Das ermöglicht große Projekte mit einer schlanken Organisation. Es gibt zudem technische Vorteile: Microservices lassen sich unabhängig skalieren, und der Ausfall eines Service beeinflusst die anderen nicht. Je kleiner er ist, desto größer der Vorteil – aber wo liegt die Grenze für die Größe eines Microservice? Für noch kleinere Nanoservices sind einige Kompromisse notwendig.

In der Vergangenheit war die Modularisierung eines Softwaresystems meistens nur für Entwickler relevant – schließlich sollten sie die Module getrennt weiterentwickeln. Später wird die gesamte Anwendung auf einmal in den Betrieb überführt: Sie ist also ein Deployment-Monolith. Microservices teilen Anwendungen auch beim Deployment in kleine Einheiten auf. Das Besondere ist, dass sie sich einzeln in Produktion bringen lassen.

Ein Beispiel: Eine E-Commerce-Anwendung hat jeweils Module für den Bestellprozess, für die Produktsuche oder für Empfehlungen. Sind diese Fachlichkeiten als Microservices implementiert, können neue Versionen einzeln in Produktion gebracht werden. Jede dieser Fachlichkeiten lässt sich außerdem in mehrere Microservices aufteilen.

Microservices sind in virtuelle Maschinen oder Docker-Container verpackt: So können sie Bestandteile wie eine eigene Datenbank oder einen Webserver mitbringen und dennoch einzeln deployt werden. Dadurch lassen sich Microservices praktisch in jeder Programmiersprache und auf jeder Plattform implementieren. Im Beispiel kann also jeder Microservice einen Teil der Oberfläche für die Kunden beisteuern.

Microservices haben einige Vorteile, etwa die Entkopplung der Entwicklung durch unabhängige Deployments. Beispielsweise kann ein Team den Bestellprozess eigenständig weiterentwickeln, ohne dass dazu viel Interaktion mit anderen Teams notwendig ist. Schließlich lassen sich für jeden Microservice unterschiedliche Technologien nutzen, sodass ihre Koordination im gesamten Projekt nicht unbedingt notwendig ist. Außerdem kann das Team Änderungen am Microservice ausrollen, ohne das mit den anderen Teams zu koordinieren.

Diese Eigenschaften ermöglichen es, dass auch in einem großen System kleine Teams ohne großen Overhead viele neue Features parallel entwickeln und in Produktion bringen. Aber es gibt noch ganz andere Gründe für Microservices. Beispielsweise sind sie gegeneinander isoliert. Wenn ein Service abstürzt, beeinflusst das die anderen nicht. Ganz anders beim Deployment-Monolithen: Hat ein Modul ein Speicherleck, reißt es beim Absturz das gesamte System mit sich und damit auch alle anderen Module.

Die Größe eines Microservice

Für Microservices gilt eigentlich, dass kleiner besser ist:

• Ein Microservice sollte von nur einem Team weiterentwickelt werden. Daher darf ein solcher Service auf keinen Fall so groß sein, dass mehrere Teams an ihm entwickeln müssen.
• Microservices sind ein Modularisierungsansatz. Entwickler sollten einzelne Module verstehen können – daher müssen Module und damit Microservices so klein sein, dass alle Entwickler sie noch verstehen.
• Schließlich soll ein Microservice ersetzbar sein. Ist er nicht mehr wartbar oder soll beispielsweise eine leistungsfähigere Technologie genutzt werden, lässt er sich durch eine neue Implementierung austauschen. Microservices sind damit der einzige Ansatz, der bereits bei der Entwicklung die Ablösung des Systems oder zumindest von Teilen davon betrachtet.

Die Frage ist nun, warum man die Microservices nicht möglichst klein baut. Dafür gibt es mehrere Gründe:

• Verteilte Kommunikation zwischen Microservices über das Netz ist mit großem Aufwand verbunden. Sind sie größer, ist die Kommunikation eher lokal in einem Microservice und damit weniger aufwendig.
• Jeder Microservice muss unabhängig in Produktion gebracht werden und daher eine eigene Umgebung haben. Das verbraucht Hardwareressourcen und bedeutet, dass der Aufwand für die Administration des Systems steigt. Wenn es größere und damit weniger Microservices gibt, sinkt dieser.

Die ideale Größe eines Microservice ist also nicht fest, sondern hängt von den genutzten Technologien ab. Wenn sie nicht sehr effizient sind, wird er entsprechend groß sein müssen, damit sich der Aufwand für das Bereitstellen der Umgebungen noch rechtfertigen lässt.