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.