Servicebasierte Architektur und serviceorientierte Architektur

Zwischen Monolith und Microservices

Ein Großteil der Diskussion in der Branche stellt eine Wahl zwischen einem Monolithen und vielen Microservices dar. In der Praxis liegt ein großer Teil realer Systeme dazwischen: eine Handvoll separat deployter Services, die jeweils einen ganzen Geschäftsbereich abdecken und sich oft noch eine Datenbank teilen. Mark Richards und Neal Ford haben diesen Stil in Fundamentals of Software Architecture servicebasierte Architektur genannt und halten ihn für einen der pragmatischsten verteilten Stile überhaupt. Dieser Abschnitt beschreibt ihn, grenzt ihn von der älteren serviceorientierten Architektur (SOA) ab, mit der er oft verwechselt wird, und zeigt, worin sich Microservices von beiden unterscheiden.

Servicebasierte Architektur: die Topologie

Ein servicebasiertes System hat drei Teile. Eine oder mehrere Benutzeroberflächen rufen eine Reihe separat deployter Domain Services auf, die jeweils einen großen, zusammenhängenden Geschäftsbereich wie Bestellungen oder Zahlungen abdecken. Richards und Ford beobachten, dass solche Systeme meist zwischen 4 und 12 Domain Services haben, im Durchschnitt etwa 7. Die Services teilen sich meist eine Datenbank, und eine optionale API-Schicht (ein Reverse Proxy oder Gateway) kann zwischen den Benutzeroberflächen und den Services liegen und Routing, Authentifizierung und Rate Limiting übernehmen.

Jeder Domain Service ist grobgranular: Er enthält alles, was seine Domäne braucht, von der API über die Geschäftslogik bis zum Datenzugriff, und ist intern wie ein kleiner Monolith aufgebaut, oft in Schichten oder Modulen (Kapitel 5). Ein Service wird typischerweise als einige Instanzen hinter einem Load Balancer deployt.

Daraus folgen zwei Konsequenzen. Erstens laufen die meisten Geschäftsabläufe vollständig innerhalb eines Service und können daher eine gewöhnliche lokale Datenbanktransaktion mit vollen ACID-Garantien nutzen (Kapitel 0). Zweitens müssen sich Domain Services selten gegenseitig aufrufen: Eine Anfrage von der Benutzeroberfläche geht an den einen Service, dem die Domäne gehört. Das hält synchrone Ketten kurz, was aus den in Abschnitt 6.1 berechneten Gründen wichtig ist.

Die gemeinsame Datenbank und wie man sie zähmt

Eine gemeinsame Datenbank macht servicebasierte Architektur günstig und einfach: keine Datensynchronisation zwischen Services, keine Eventual Consistency, Reporting mit gewöhnlichem SQL. Sie ist zugleich ihre Hauptschwäche. Lesen und schreiben alle Services dieselben Tabellen, kann eine Änderung an den Spalten einer Tabelle mehrere Services kaputt machen, die dann alle gemeinsam getestet und neu deployt werden müssen. Die Definition aus Kapitel 5 gilt: Services, die sich eine Datenbank teilen, sind zu einem Architekturquantum verbunden, sie teilen also ein Verfügbarkeitsniveau und einen Rhythmus für Schema-Releases.

In der Praxis gibt es drei Techniken, um die Kopplung zu verringern. Die erste ist logische Partitionierung: Jeder Service erhält sein eigenes Schema (oder seinen eigenen Satz von Tabellen) und darf die der anderen nicht anfassen, durchgesetzt sowohl durch Datenbankberechtigungen als auch durch Konvention. Die zweite besteht darin, die Entity-Klassen der gemeinsamen Datenbank in kleinen Bibliotheken pro Domäne statt in einer großen gemeinsamen Bibliothek zu halten, sodass eine Änderung an Restauranttabellen nur die Services betrifft, die sie nutzen. Die dritte besteht darin, einem Service eine eigene Datenbank zu geben, wenn er einen triftigen Grund hat, etwa den Sicherheitsumfang, ein ganz anderes Lastmuster oder eine andere Art von Datenspeicher. Teams, die diese Techniken konsequent anwenden, stellen fest, dass ein späterer Wechsel zu getrennten Datenbanken, falls er je nötig wird, viel leichter fällt.

Klassische serviceorientierte Architektur

Serviceorientierte Architektur ist älter und breiter angelegt. Der Begriff kam 1996 durch einen Gartner-Bericht von Roy Schulte und Yefim Natis in die Branche, und ab den frühen 2000er-Jahren wurde sie zum vorherrschenden Modell der Unternehmensintegration. Ihre Kernidee war vernünftig: Geschäftsfähigkeiten als Services mit expliziten, technologieneutralen Verträgen bereitstellen, sodass Anwendungen in einer großen Organisation daraus zusammengesetzt werden können, statt neu gebaut oder Punkt zu Punkt integriert zu werden.

Was die meisten Unternehmen tatsächlich bauten, war jedoch das, was Richards und Ford orchestrierungsgetriebene SOA nennen. Services wurden in technischen Schichten angeordnet: Business Services, die Prozesse beschreiben (Bestellung aufgeben, Konto eröffnen), gemeinsame Enterprise Services, die wiederverwendbare Fähigkeiten bereitstellen (Kunde, Preisgestaltung, Rechnung), sowie Application und Infrastructure Services, die bestehende Systeme und technische Anliegen kapseln. Im Zentrum saß ein Enterprise Service Bus (ESB): Middleware, die Nachrichten weiterleitete, zwischen Formaten umwandelte, zwischen Protokollen vermittelte und über eine Orchestrierungs-Engine die Geschäftsprozesse selbst ausführte.

Zwei weitere Ideen vervollständigten das Bild. Ein kanonisches Datenmodell definierte eine unternehmensweite Darstellung jeder Geschäftsentität (ein Customer, ein Order), und jede Nachricht wurde im Bus in diese Darstellung und aus ihr übersetzt. Und eine Familie von Webservice-Standards, meist WS-* genannt, legte fest, wie Services einander beschreiben und aufrufen: SOAP für Nachrichten, WSDL für Schnittstellenbeschreibungen, UDDI für Registries, WS-Security, WS-ReliableMessaging und WS-AtomicTransaction für Qualitäten und WS-BPEL (Version 2.0, 2007 von OASIS verabschiedet) für ausführbare Prozessdefinitionen.

Warum die klassische SOA in Ungnade fiel

Ende der 2000er-Jahre hatten viele SOA-Programme enttäuscht. Anne Thomas Manes von der Burton Group fasste die Stimmung im Januar 2009 in einem viel gelesenen Beitrag mit dem Titel SOA is Dead; Long Live Services zusammen: Das Etikett war toxisch geworden, aber die Idee der Services überlebte. Die Gründe sind wissenswert, denn jeder ist eine Falle, in die moderne Architekturen erneut tappen können.

Wiederverwendung erzeugte Kopplung. Ein gemeinsamer Enterprise-Customer-Service, den vierzig Anwendungen nutzten, konnte sich nicht ändern, ohne dass vierzig Consumer zustimmten; die Wiederverwendung, das Hauptziel, machte jede Änderung zur Verhandlung. Der Bus wurde zum Engpass. Routing, Transformation und Prozesslogik in einen zentralen ESB zu legen, der meist einem einzigen Integrationsteam gehörte, bedeutete, dass fast jede geschäftliche Änderung dieses Team brauchte, und der Bus wurde zu einem Single Point of Failure und der Verzögerung. Das kanonische Modell war zu groß. Eine Definition von Customer, die Vertrieb, Abrechnung, Support und Logistik zufriedenstellt, ist entweder riesig oder für die meisten von ihnen falsch; die Bounded Contexts aus Kapitel 5 erklären, warum ein Begriff in verschiedenen Teilen eines Unternehmens berechtigterweise Verschiedenes bedeutet. Die Standards waren schwerfällig. WS-*-Spezifikationen waren komplex, die Werkzeuge teuer, und verteilte Transaktionen über Services hinweg erwiesen sich als fragil. Technische Partitionierung bedeutete, dass ein einfaches Feature mehrere Schichten von Services durchquerte, die verschiedenen Gruppen gehörten.

Die bleibenden Lehren sind die, auf denen Microservices aufgebaut wurden: explizite Serviceverträge, Services, die denen gehören, die sie bauen, Logik in den Services statt in der Middleware und Daten, die einem Service gehören, statt im ganzen Unternehmen geteilt zu werden.

Worin sich Microservices unterscheiden

Microservices, die im nächsten Abschnitt ausführlich behandelt werden, behalten die SOA-Idee von Services mit expliziten Verträgen bei und kehren die meisten ihrer Umsetzungsentscheidungen um. James Lewis und Martin Fowler fassten eine dieser Umkehrungen als Smart Endpoints and Dumb Pipes zusammen: Das Netzwerk transportiert nur Nachrichten, und die gesamte Logik liegt in den Services. Services sind um Geschäftsfähigkeiten statt um technische Schichten organisiert, Wiederverwendung ist der Unabhängigkeit bewusst nachgeordnet, jeder Service besitzt seine Daten, und Governance ist dezentralisiert.

Verglichen mit servicebasierter Architektur sind Microservices feingranularer, weit zahlreicher und bestehen auf getrennten Daten. Das bringt mehr Unabhängigkeit, gezieltere Skalierung und mehr Fehlerisolation und kostet viel mehr an Betrieb, Konsistenz und Koordination. Servicebasierte Architektur lässt sich als der Punkt im Spektrum sehen, an dem der Großteil des Nutzens für Deployment und Teams zu einem Bruchteil der Kosten eintritt.

Wann servicebasierte Architektur der pragmatische Mittelweg ist

Wählen Sie sie, wenn das System wenige klare Geschäftsdomänen hat, wenn zwei bis vielleicht acht Teams unabhängig ausliefern müssen, wenn die meisten Abläufe natürlicherweise innerhalb einer Domäne bleiben und wenn starke Konsistenz innerhalb einer Domäne wertvoll ist. Sie ist außerdem ein ausgezeichneter Migrationsschritt aus einem Monolithen heraus: Einen gut modularisierten Monolithen in eine Handvoll Domain Services zu zerlegen ist weit weniger riskant als der Sprung zu fünfzig Microservices, und das Ergebnis ist oft gut genug, um dort aufzuhören.

Vermeiden Sie sie oder planen Sie, über sie hinauszugehen, wenn Teile einer Domäne sehr unterschiedliche Skalierbarkeit oder Verfügbarkeit brauchen (sie gehören in getrennte Quanten), wenn Dutzende Teams Autonomie brauchen, wenn die gemeinsame Datenbank zum Engpass für Schreibvorgänge geworden ist oder wenn sich die Domain Services ständig gegenseitig aufrufen, um gewöhnliche Anfragen zu erledigen, was ein Zeichen dafür ist, dass die Grenzen falsch sind.