Microservices in Anwendungen: Anwendungsfälle, die im Alltag auftauchen

Microservices sind zum Synonym für Modernität geworden. Viele Leute übernehmen sie, weil „große Unternehmen sie nutzen“, ohne die einzig wichtige Frage zu stellen: Welches konkrete Problem lösen sie heute für mich?

Dieser Text kehrt den Ansatz um. Anstatt die Architektur abstrakt zu erklären, geht man von realen Anwendungsfällen aus, Situationen, die im täglichen Leben derjenigen auftreten, die ein Produkt bedienen, und in denen die Aufteilung des Systems in unabhängige Dienste keine Theorie mehr ist, sondern eine praktische Lösung wird.

Denn Microservices sind nicht objektiv. Es ist ein Werkzeug. Und wie jedes Werkzeug glänzt es in manchen Fällen und stört in anderen. Das Wissen, wie man unterscheidet, ist das, was eine Entscheidung im Bereich Modetechnik von einem Lebenslauf unterscheidet.

Was sind Microservices, in einem ehrlichen Satz

Microservices sind eine Möglichkeit, ein System als eine Reihe kleiner und unabhängiger Dienste zu organisieren, von denen jeder für eine Geschäftsfähigkeit verantwortlich ist und über klar definierte Schnittstellen kommuniziert.

Das Gegenteil ist der [Monolith: alles in einer einzigen Anwendung, in einem einzigen Prozess, in einem einzigen Deployment. Keines von beiden ist grundsätzlich richtig oder falsch. Der Unterschied besteht darin, wann jeder einzelne Sinn ergibt. Und gerade in alltäglichen Anwendungsfällen wird dieser Unterschied sichtbar.

Fall 1: Teile des Systems, die ungleichmäßig skalieren

Der häufigste Fall tritt auf, wenn ein Teil der App viel stärker nachgefragt wird als der Rest.

Denken Sie an eine E-Commerce-Anwendung. Die Produktsuche erhält eine große Menge an Anfragen; Benutzerregistrierung, fast nichts. In einem Monolith ist man gezwungen, alles zusammen zu erklimmen, man zahlt für ungenutzte Kapazität, nur weil die Suche Atempause braucht.

Indem Sie die Suche in einen eigenen Dienst aufteilen, skalieren Sie nur das, was Sie brauchen, und zwar dann, wenn Sie es brauchen. Im Alltag führt dies zu Einsparungen bei der Infrastruktur und der Ausfallsicherheit: Ein Anstieg der Suche führt nicht zum Ausfall des Bezahlvorgangs. Dies ist einer der Fälle, in denen sich Microservices amortisieren.

Fall 2: Teams, die zusammenarbeiten müssen, ohne sich gegenseitig zu überfallen

Ein anderer Fall entsteht, wenn das Team wächst und anfängt, über sich selbst zu stolpern.

In einem großen Monolith ändern mehrere Personen denselben Code, Bereitstellungen werden zu einer Warteschlange und eine Änderung in einer Ecke bringt eine andere weit entfernt zum Erliegen. Die Produktivität sinkt nicht aufgrund mangelnder Talente, sondern aufgrund übermäßiger Kopplung.

Wenn Sie das System in Dienste unterteilen, die auf Domänen, Zahlungen, Kataloge und Benachrichtigungen ausgerichtet sind, verfügt jedes Team über seine eigenen, stellt sie in ihrem eigenen Tempo bereit und macht weniger Dinge der anderen kaputt. Im Alltag bedeutet das, schneller und mit weniger Koordination zu liefern. Es handelt sich sowohl um einen organisatorischen als auch um einen technischen Anwendungsfall.

Das praktische Zeichen, dass die Zeit gekommen ist

Sie wissen, dass dieser Fall zutrifft, wenn die Zeit zwischen „Code bereit“ und „Code in Produktion“ länger wird, weil Teams aufeinander warten müssen. Diese Koordinationsreibung ist das Symptom. Microservice erkauft hier Autonomie.

Fall 3: Unterschiedliche Technologien für unterschiedliche Probleme

Es gibt Situationen, in denen Teile des Systems so unterschiedliche technische Anforderungen haben, dass es kontraproduktiv ist, sie in denselben Stapel zu zwingen.

Ein Bildverarbeitungsdienst kann von einer leistungsorientierten Sprache profitieren. Ein Geschäftsregeldienst kann Produktivität anfordern. Für eine Datenkomponente ist möglicherweise eine spezielle Datenbank erforderlich. In monolith wählt man einen Stapel für alles und macht an jedem Ende Zugeständnisse.

Microservices ermöglichen es Ihnen, für jeden Service das richtige Tool zu verwenden. Im Alltag werden dadurch Workarounds vermieden und die Leistung dort verbessert, wo es darauf ankommt. Das ist ein überzeugender und zugleich gefährlicher Fall, denn zu viel technologische Vielfalt wird zum Wartungsalptraum. Sparsam verwenden.

Fall 4: Isolieren Sie, was nicht gemeinsam scheitern kann

Ein weniger offensichtlicher Anwendungsfall ist die Risikoisolierung.

In Systemen, in denen einige Funktionen kritisch sind und andere nicht, bedeutet das Zusammenfügen aller Elemente, dass ein einfacher Fehler das Wesentliche zerstören kann. Stellen Sie sich eine App für einen Terminplanungsdienst für das öffentliche Gesundheitswesen vor: Das Management-Reporting-Modul kann unter keinen Umständen die Terminplanung des Bürgers aufheben.

Durch die Trennung des Kritischen vom Zubehör wird der Schadensradius begrenzt. Wenn Berichte hängen bleiben, wird die Planung fortgesetzt. Im öffentlichen Sektor, wo die Kontinuität der Dienstleistungen in der direkten Verantwortung des Bürgers liegt, ist diese Isolation kein Luxus mehr, sondern eine Projektanforderung.

Reflexion: Wenn Microservices die falsche Antwort sind

Reife erfordert das Erkennen der Fälle, in denen diese Architektur schädlich ist.

Für ein kleines Produkt im Frühstadium mit einem schlanken Team sind Microservices fast immer übertrieben. Sie erhalten die Komplexität verteilter Systeme, instabile Netzwerke, schwierige Datenkonsistenz und verstreute Beobachtbarkeit, ohne das Problem zu haben, das sie lösen. Es kommt häufig vor, dass Start-ups Monate damit verbringen, Dutzende Dienste für hundert Benutzer zusammenzustellen. Das ist keine Raffinesse, sondern Selbstsabotage.

Verteilte Komplexität ist real. Ein Anruf, der in einem Monolith] trivial ist, wird zwischen Diensten zu einem Netzwerkanruf, der fehlschlagen, Latenz haben und eine Fehlerbehandlung erfordern kann. Das Debuggen eines Problems, das sich über fünf Dienste erstreckt, ist viel schwieriger als mit einzelnem Code. Diese Kosten sind dauerhaft und Sie zahlen sie jeden Tag.

Die kluge Regel: Beginnen Sie monolithisch, intern gut organisiert und migrieren Sie zu Microservices, wenn ein konkreter Anwendungsfall wie die oben genannten tatsächlich auftritt. Architektur sollte dem Problem folgen, nicht der Mode.

Schließung

Microservices sind keine Trophäe der Moderne. Sie sind eine Reaktion auf spezifische Probleme: ungleiche Größe, übereinanderlaufende Teams, unterschiedliche technische Anforderungen, Risiken, die isoliert werden müssen. Wenn diese Fälle in Ihrem Alltag auftauchen, strahlen sie. Wenn nicht, erhöhen sie lediglich das Gewicht.

Gutes Engineering fragt nicht: „Was ist die fortschrittlichste Architektur?“ Fragen Sie: „Welches Problem habe ich jetzt und wie kann ich es am einfachsten lösen?“ Microservice ist oft die richtige Antwort und oft der teuerste Projektfehler.

Wenn Sie entscheiden, ob sich eine Teilung Ihres Systems lohnt, lohnt es sich, zunächst einen Blick auf die tatsächlichen Symptome Ihrer Operation zu werfen. Ich habe auf dem Blog weitere Texte über Architektur, Skalierbarkeit und Monolith im Vergleich zu Microservices, und wenn Sie über Ihren Fall nachdenken möchten, ist das ein gutes Gespräch.