Bauen Sie keine Microservices auf, sondern verfolgen Sie eine lose Kopplung

Sep 01, 2023

Von: Chris Bertinato am 29. August 2023

Angesichts der ständig wachsenden Nachfrage nach zuverlässiger Anwendungsleistung ist es keine Überraschung, dass viele Unternehmen ihre Systeme mit Blick auf zukünftige Erweiterungen entwickeln. Viele Branchenexperten haben darauf hingewiesen, dass Microservices der beste Weg sind, ein System zukunftssicher zu machen – es wäre jedoch möglicherweise besser, stattdessen den Begriff „Services in der richtigen Größe“ zu verwenden, da es keine einheitliche Strategie gibt, die für jedes Unternehmen zu jedem Zeitpunkt funktioniert . Anstatt darüber nachzudenken, welche der neuesten Trends sie als Strategie übernehmen sollen, sollten Teams stattdessen den zugrunde liegenden Faktor der Kopplung erkennen und sich darauf konzentrieren. Systeme sind flexibler und dynamischer, wenn eine lose Kopplung zwischen den Komponenten besteht, die sich am wahrscheinlichsten ändern.

Unter Kopplung versteht man im Systemkontext die Art und Weise, wie Komponenten eines Systems miteinander verbunden sind. Zur losen Kopplung sind Schnittstellen notwendig. Bei elektrischen Systemen werden diese Schnittstellen als physische Anschlüsse mit Stiften und Buchsen sowie Protokollen implementiert, die anhand von Spannungspegeln beschrieben werden. Die Analogie eines Softwaresystems zu einem elektrischen Steckverbinder ist eine Anwendungsprogrammierschnittstelle (API), die unter anderem als eine Reihe von Funktionen oder HTTP-basierten Ressourcen implementiert werden könnte. Eine Schnittstelle allein reicht für eine lose Kopplung jedoch nicht aus. Diese Schnittstelle muss auch einigermaßen stabil sein, das heißt, ein Benutzer kann sich darauf verlassen, dass diese Schnittstelle vorhanden ist und ihre Eingaben über einen langen Zeitraum gleich bleiben oder sich zumindest vorhersehbar ändern.

Wenn Komponenten eines Systems lose gekoppelt sind, können diese Komponenten intern geändert werden, ohne den Rest des Systems wesentlich zu beeinträchtigen. Betrachten Sie ein alltägliches Beispiel: Die Glühbirne. Glühbirnenfassungen haben eine Standardgröße mit Standardgewinde und einer Standardspannung. Die Glühbirne selbst hat sich über verschiedene Materialien für den Glühfaden zu LEDs weiterentwickelt, ohne dass eine Änderung an Lampen und Leuchten erforderlich war. Betrachten Sie nun ein einfaches Beispiel in Softwaresystemen: einen HTTP-Server und einen Datenspeicher, beispielsweise einen Cache, eine Warteschlange oder eine Datenbank. In den meisten Fällen wäre es von Vorteil, eine Schnittstelle zwischen dem Server und dem Datenspeicher einzurichten, die eine Änderung der Implementierung des Datenspeichers erleichtert. Sobald diese beiden Komponenten nur lose gekoppelt sind, können Dinge, die sich wahrscheinlich ändern, dies tun, ohne dass wesentliche Änderungen an den anderen Dingen erforderlich sind.

Wenn die Komponenten Ihres Systems zu eng miteinander verflochten sind, kann selbst die kleinste Änderung an anderer Stelle im System verheerende Folgen haben. Man könnte diese Struktur mit einer Gruppe von Pflanzen vergleichen, die in unmittelbarer Nähe wachsen. Da alle Stängel miteinander verflochten sind, wird der Versuch, eine Pflanze gegen eine neue auszutauschen, eine Herausforderung sein, da eine falsche Bewegung leicht viele andere Pflanzen entwurzeln könnte.

Im Gegensatz dazu können in einem lose gekoppelten System Änderungen mit der Gewissheit vorgenommen werden, dass der Rest des Systems stabil bleibt, wenn bei einer Komponente ein Problem auftritt. Dieses Vertrauen führt zu größerer Flexibilität bei der Durchführung von Änderungen, ermöglicht eine kürzere Markteinführungszeit für neue Funktionen und Produkte und verschafft möglicherweise einen Wettbewerbsvorteil.

Ein weiterer Vorteil der losen Kopplung ist die Weiterentwicklungsfähigkeit: Wenn sich Schnittstellen an den Stellen befinden, an denen Änderungen am wahrscheinlichsten sind, kann sich das System leichter weiterentwickeln. Schnittstellen sollen stabil und undurchsichtig sein, sodass alles, was sich hinter ihnen abspielt, im Allgemeinen unbekannt und für den Benutzer dieser Schnittstelle irrelevant ist. Solange die Schnittstellen also stabil bleiben, können sich die Systeme dahinter frei verändern und somit weiterentwickeln.

Es stimmt zwar, dass Microservices-Strategien die lose Kopplung unterstützen, sie sind jedoch nicht die einzige Möglichkeit. Einfachere Architekturstrategien können kleineren oder neueren Projekten die Vorteile der losen Kopplung auf nachhaltigere Weise bieten und weniger Overhead erzeugen als der Aufbau einer auf Mikrodienste ausgerichteten Infrastruktur.

Bei architektonischen Entscheidungen geht es sowohl um die menschliche Komponente beim Erstellen und Betreiben von Softwaresystemen als auch um technische Aspekte wie Skalierbarkeit und Leistung. Und bei der menschlichen Komponente können Microservices zu kurz kommen.

Beim Entwurf eines Systems sollte man zwischen absichtlicher Komplexität (wobei ein komplexes Problem zu Recht eine komplexe Lösung erfordert) und unbeabsichtigter Komplexität (wobei eine übermäßig komplexe Lösung unnötige Herausforderungen schafft) unterscheiden. Es stimmt, dass Firmen wie Netflix stark von Microservices-basierten Architekturen mit absichtlicher Komplexität profitiert haben. Aber ein aufstrebendes Startup ist nicht Netflix, und der Versuch, in die Fußstapfen des Streaming-Titanen zu treten, kann ein hohes Maß an unbeabsichtigter Komplexität mit sich bringen.

Der Microservices-Ansatz ist eine Möglichkeit, die Komplexität eines Systems zu verwalten, wenn es zu groß geworden ist, um es sicher handhaben zu können. Dennoch gibt es einen Kompromiss zwischen Komplexität und Overhead. Mit der Verwaltung einer Reihe von Diensten ist ein erheblicher Mehraufwand verbunden. Bei vorzeitiger Einführung kann ein Microservices-Ansatz dazu führen, dass Mitarbeiter ihre ganze Zeit damit verbringen, die Tools zu unterstützen, die die Services unterstützen, und das eigentliche Produkt vernachlässigen.

Für jedes Team, das flexibel bleiben möchte, indem es eine lockere Kopplung fördert, und Fortschritte erzielen möchte, indem es den Aufwand für die Wartung einer auf Mikrodiensten basierenden Infrastruktur vermeidet, gibt es mindestens zwei Optionen, die eine Überlegung wert sein könnten.

Die erste Möglichkeit besteht darin, eine monolithische Architektur zu übernehmen. Während Monolithen oft als unflexibel und veraltet angesehen werden, kann ein richtig geplanter Monolith eine lose Kopplung unterstützen und erfordert viel weniger Unterstützungsaufwand. Der Schlüssel besteht darin, eine codebasierte Schnittstelle zu erstellen, die die Eingaben einer Komponente an eine andere weiterleiten kann. Selbst wenn eine Komponente des Monolithen geändert wird, minimiert eine solche Schnittstelle die Auswirkungen auf alle anderen Komponenten und das System kann sich dort, wo Schnittstellen vorhanden sind, leichter weiterentwickeln.

Die zweite Möglichkeit besteht darin, eine serverlose Plattform zu nutzen, die von einem großen Cloud-Anbieter bereitgestellt wird. Dieser Ansatz kommt im Geiste viel näher an Microservices heran, die Gemeinkosten werden jedoch vom Cloud-Anbieter übernommen. Dadurch kann eine serverlose Architektur die Vorteile einer losen Kopplung bei minimaler unbeabsichtigter Komplexität nutzen. Möglicherweise ist Serverless aufgrund anderer Einschränkungen nicht das Richtige für Sie, aber solange Sie Ihre Schnittstellen sorgfältig konstruieren und sich auf die Interaktionen konzentrieren, die sich in Zukunft am wahrscheinlichsten ändern werden, kann es nicht schaden, es zunächst mit Serverless zu versuchen.

Selbst wenn Sie sich für eine dieser beiden Strategien zur losen Kopplung entscheiden, ist es möglicherweise nicht klar, welche Sie wählen sollen. Hier sind einige Faktoren, die Ihnen bei der Entscheidung helfen können, ob Sie sich für monolithische oder serverlose cloudbasierte Architekturen entscheiden sollten:

Das Ziel besteht nicht darin, überall zu entkoppeln, und auch nicht darin, dass alles lose gekoppelt ist. Vielmehr geht es darum, das System entwicklungsfähig zu machen, indem strategisch ausgewählt wird, wo und wie stark Komponenten lose gekoppelt werden. Dies ist ein Spiel mit fundierten Vermutungen und Kompromissen. Es gibt keinen besten Weg, nur den am wenigsten schlechtesten.

Wenn Analysten und Branchenführer von „Microservices“ sprechen, als ob dies die universelle Antwort für Softwaresysteme sei, gilt dies nur für Teams, die die ausgereiftesten Systeme entwickeln, die in der Lage sind, den damit verbundenen Overhead zu bewältigen. Der Begriff „Services in der richtigen Größe“ bringt besser zum Ausdruck, dass jedes Team auch innerhalb eines Unternehmens unterschiedliche Einschränkungen hat und daher unterschiedliche Möglichkeiten hat, eine lose Kopplung zu erreichen. Dies kann den Einsatz von Microservices, Monolithen, serverlosen Plattformen oder einer Mischung dieser Dinge beinhalten; Aber auf jeden Fall sind Teams, die sich für eine lockere Kopplung einsetzen, besser gerüstet, um auf Herausforderungen zu reagieren, sich einen Wettbewerbsvorteil zu verschaffen und sich an eine sich ständig verändernde Technologielandschaft anzupassen.

Abgelegt unter: API, Blogs, DevOps-Praxis, DevOps-Toolbox. Markiert mit: Anwendungsentwicklung, Architektur, Cloud-native Anwendungen, Microservices