Miniservices statt Microservices

Der Umstieg von Monolithen auf Micro­services ist alles andere als ein Katzensprung - Miniservices kommen nun als vermeintlich greifbarere Alternative ins Gespräch. Doch was sind die Unterschiede?

Unternehmen - junge wie etablierte - stehen gegenwärtig vor vielfältigen Herausforderungen in der Anwendungsentwicklung und im IT-Betrieb. Da immer mehr Geschäftsmodelle und -prozesse auf Software basieren, müssen Anwendungen heute skalierbarer, leistungsstärker, nutzerfreundlicher und zuverlässiger sein als in der Vergangenheit. Zudem sorgen Internet und Globalisierung für mehr Wettbewerb: Wer früher nur mit Anbietern in unmittelbarer Nachbarschaft konkurrierte, verliert den nächsten Auftrag vielleicht nach China oder Indien. Diese verschärfte Konkurrenz erhöht den Druck, das eigene Angebot fortlaufend weiterzuentwickeln und um neue Funktionalitäten zu erweitern.

Um diese Herausforderungen besser bewältigen zu können, steigen immer mehr Unternehmen auf DevOps um. Den Analysten von Forrester zufolge implementieren weltweit mittlerweile 50 Prozent der Unternehmen diesen Ansatz, Tendenz steigend. Damit einher geht oft eine Reform der Anwendungsarchitektur. Monolithen werden aufgebrochen und durch flexiblere Strukturen ersetzt, autonome Teams beackern fortan ihre jeweils eigenen Parzellen. Microservices sind hier der Idealtypus: winzige, ereignisgesteuerte Dienste, die vollständig voneinander entkoppelt sind und jeweils nur eine einzige Geschäftsfunktion haben - ganz im Sinne der Unix-Philosophie „Do one thing and do it well“.

Das Aufbrechen eines Monolithen in Microservices ist selbstverständlich nicht ganz trivial. Einerseits existieren hier technische Hürden, andererseits lassen sich die über Jahre gewachsenen organisatorischen Strukturen in der IT nicht ohne Weiteres umkrempeln. Darüber hinaus stellt sich immer die Sinnfrage. Denn die Neugestaltung der Anwendungsarchitektur ist ja kein Selbstzweck, sondern muss stets auf Geschäftsziele ausgerichtet bleiben. Vor diesem Hintergrund fordert eine zunehmende Zahl an Experten für Anwendungsarchitektur eine Abkehr von der puristischen Microservice-Definition und mehr Pragmatismus bei der Implementierung. Sie sprechen von Miniservices - eine Maßeinheit größer - und meinen Dienste, die zwar bestimmte Aspekte der Definition erfüllen, andere aber nicht.

Die vollständige Entkoppelung einzelner Dienste im Rahmen einer ereignisgesteuerten Architektur etwa bedeutet zwar enormen Aufwand, schafft in vielen Fällen aber gar keinen zusätzlichen Mehrwert. Althergebrachte Ansätze, wie eine Kommunikation über HTTP-basierte APIs, erscheinen dann als wesentlich sinnvollere Alternative, auch wenn dabei eine lose Koppelung bestehen bleibt. Denn die Hauptziele der Migration auf Microservices, nämlich einzelne Dienste unabhängig voneinander managen und skalieren zu können, werden trotzdem erreicht.

Im Alltag der meisten Unternehmen ist diese pragmatische Herangehensweise übrigens durchaus üblich, häufig sprechen die Verantwortlichen aber dennoch von Microservices. Die strenge Definition der Evangelisten hat sich unter den Praktikern bislang nicht durchgesetzt - und die Grenzen zwischen Micro- und Miniservice sind ohnehin fließend. IT-Verantwortliche sollten sich deshalb nicht zu sehr an den Begrifflichkeiten aufhängen, sondern konkrete Probleme in den Blick nehmen und nach passenden Lösungen suchen.

Unabhängig von der Frage, in wie viele Teile Monolithen aufgespalten und wie weitgehend einzelne Dienste voneinander entkoppelt werden, stehen IT-Entscheider vor einer zentralen Herausforderung: Die Gesamtverantwortung für die Dienste bleibt bei ihnen, auch wenn die einzelnen Service-Teams nun autonom agieren. Die Anwendung muss weiterhin die Geschäftsanforderungen erfüllen, außerdem müssen Stabilität und Performance stets gewährleistet sein. Fehler fallen zwangsläufig auf das Management zurück.

Sowohl für Miniservices als auch für Microservices - wenn man diese Unterscheidung machen will - ist ein umfassendes Monitoring vor diesem Hintergrund unverzichtbar. Bedarf herrscht bereits in der Migrationsphase, denn es gilt sicherzustellen, dass die Anwendung nach der Umstellung weiterhin flüssig läuft und sich die Servicequalität nicht verschlechtert hat. Nur mit historischen Vergleichsdaten lässt sich diese Frage eindeutig beantworten.

Zwei Aspekte sind zu bedenken: Erstens ist der einzelne Microservice dem Ideal nach zwar simpel und überschaubar, die Anwendungslandschaft insgesamt gewinnt durch die Umstellung aber zwangsläufig an Komplexität. Zumindest potenziell ruht jeder Dienst auf einem eigenen Technology-Stack, nutzt eine eigene Datenbank und einen eigenen Hosting-Provider. Das große Ganze weiter im Blick zu behalten, ist nicht ganz trivial. Wenn IT-Entscheider aber der erwähnten Gesamtverantwortung gerecht werden und Kontrollmöglichkeiten behalten wollen, müssen sie genau dazu in der Lage sein.

Zweitens müssen sie auch die neuen Anforderungen der Entwicklerteams berücksichtigen: Während diese sich bislang nicht für Infrastruktur-Monitoring interessierten und mit kleinteiligen Monitoring-Lösungen gut bedient waren, sind sie nach dem Umstieg auf DevOps auf ein entsprechendes Tool oftmals geradezu angewiesen. Auch beim Monitoring lohnt es sich also, sich konkrete Anforderungen zu vergegenwärtigen und eine passende Lösung auszuwählen.

„Was ist ein Name? Was uns Rose heißt, wie es auch hieße, würde lieblich duften“, so lautet eine bekannte Stelle in Shakespeares „Romeo und Julia“. Tatsächlich kommt es auch beim Aufbrechen von Monolithen nicht darauf an, ob man das Ergebnis am Ende als Microservice- oder Miniservice-Architektur bezeichnet. Puristen werden weiter auf einer vollständigen Entkoppelung bestehen und Pragmatiker werden dem widersprechen. In der Praxis kommt es für Unternehmen darauf an, einen gangbaren Weg zu finden, der mit Blick auf ihre spezifischen Voraussetzungen und Anforderungen die kleinsten Risiken birgt, die geringsten Kosten verursacht und den größten Nutzen bringt. Eine leistungsstarke Monitoring-Lösung hilft, diese Erfolgskriterien fortlaufend zu kontrollieren, und erleichtert sowohl die Migration als auch den späteren Betrieb.