Die Frage nach der optimalen Größe eines Microservice ist schwer zu beantworten. Vielleicht können wir uns der Frage nach der Größe über die minimale Größe eines Microservice annähern. Mit der minimalen Größe können wir die Frage zumindest nach einer Seite abgrenzen.
Micro kommt vom griechischen Mikros was so viel wie klein oder winzig bedeutet. In der Physik ist ein µ ein Millionstel. Das suggeriert, dass ein Mikroservice winzig klein ist. Offensichtlich ist eine Größe von einem Millionstel eines Monolithen zu klein. Micro ist daher etwas irreführend, klingt aber besser als Centi- oder Deziservices.
Je kleiner Microservices geschnitten sind, desto mehr Microservices sind notwendig, um die gleiche Aufgabe zu erledigen. Jeder weitere Service verursacht Kosten bei der Verwaltung und im Betrieb. Pro Service werden Ressourcen wie die folgenden benötigt:
- Ein Code Repository
- Eine Delivery- oder Deployment Pipeline, die den Microservice ausliefert oder installiert
- Unit- und Integrationtests
- Eine Datenbank pro Service
Zusätzliche Infrastruktur wird notwendig sobald eine gewisse Anzahl von Services überschritten wird. Die folgenden Infrastrukturdienste sind bereits ab einer moderaten Anzahl von Services nützlich. Bei mehr als einem Dutzend Microservices wird der Betrieb ohne die folgenden Infrastruktur mühselig:
- Monitoring
- Log Aggregation
- Binary Repositories ( z.B. für Maven, Docker, ...)
- Container Infrastruktur
Überschreitet die Anzahl der Services die Marke von zwei oder drei Dutzend Services, so kommt eine reine Container Infrastruktur an ihre Grenzen. Eine Cloud Plattform wie Kubernetes oder Docker Swarm wird notwendig.
Wer bereits Erfahrungen mit Microservices gesammelt hat, kennt das wahrscheinlich: Eine Umstellung auf Microservices zieht einen Ausbau der kompletten Infrastruktur mit sich. Ständig stößt man an Grenzen und benötigt weitere Werkzeuge um Betrieb oder Management in den Griff zu bekommen. In einigen Unternehmen ist die Infrastruktur für einen effizienten Betrieb von Microservices bereits vorhanden. Bei einigen Unternehmen fehlen Teile der Infrastruktur um eine große Anzahl von Microservices zu betreiben. Der Ausbau der Infrastruktur kann im Großkonzern schnell Monate oder Jahre dauern. Nicht nur die Technik, auch die Teams, die Productowner und (interne) Kunden müssen sich an agile Vorgehensweisen und an CI/CD anpassen.
Wenn die Infrastruktur und das Knowhow nicht mehr hergibt, dann kann ich aus einem Monolithen vielleicht 3 bis 5 einzelne Services heraustrennen, da die Verwaltung und der Betrieb nicht mehr hergeben. Mit zunehmendem Ausbau und Automatisierung der Infrastruktur können mit der Zeit dann weitere Services ausgegliedert werden.
Selbst wenn es aus Sicht der Fachlichkeit und der Kontextgrenzen sinnvoll wäre, Microservices besonders klein zu schneiden, sollten wir beachten, wie viele Microservices wir verwalten und betreiben können. Ein späteres Zerschneiden in zusätzliche Microservices sollte immer möglich sein. Die Zeit hilft beim Aufbau von Erfahrung beim Betrieb von Microservices.