Suche
Kolumne

EnterpriseTales: Des Microservice großer Bruder

Lars Röwekamp

(c) S&S Media

Da hat man sich gerade damit abgefunden, dass der über Jahre gewachsene Monolith aus der Mode gekommen sein soll und besser durch eine Hundertschaft von Microservices abgelöst werden sollte. Und schon erscheint ein neuer Stern am Firmament der Modularisierung. Nein, keine Angst, wir reden hier nicht über eine Reinkarnation von SOA, sondern über etwas mit deutlich höherem Potenzial: Self-contained Systems.

Mal ganz ehrlich, auch wenn die neue Wunderwelt der Microservices durchaus verlockend erscheint und man bei der Umsetzung eines Service von einigen wenigen Zeilen Code eigentlich kaum noch etwas falsch machen kann – ganz wohl ist den meisten nicht bei dem Gedanken, den über Jahre gewachsenen Monolithen in ein stark verteiltes System von mehreren hundert oder gar tausend Microservices aufzutrennen à la Netflix oder Amazon.

Weniger ist mehr

Ok, wir haben alle verstanden, dass wir mit einem historisch gewachsenen Monolithen, der von einer Heerschar von streng hierarchisch organisierten Architekten, Entwicklern, Testern und Fachexperten konzipiert und umgesetzt wird, nicht wirklich flexibel sind. Ist die Basis erst einmal ruiniert, helfen scheinbar auch Scrum und Co. nicht wirklich weiter – aber einen Versuch war es immerhin wert.

Es scheint also logisch, dass ein Auftrennen des großen Ganzen in fachlich sauber abgegrenzte Blöcke, mit möglichst wenigen Abhängigkeiten untereinander, automatisch zu besserer Software führt. So weit, so gut. Wäre da nicht die Verlagerung der Komplexität heraus aus der Fachlichkeit hinein in Themen wie Inter-Service-Kommunikation, Versionierung oder verteilte Transaktionen bzw. das Schaffen einer sich selbst heilenden Infrastruktur. Das in voller Konsequenz durchgezogene Microservice-Paradigma funktioniert nachweislich – keine Frage. Aber ist jeder von uns für diese Konsequenz bereit? Wollen wir denn wirklich ein extrem feingranulares, stark verteiltes System aufbauen oder wollen wir eigentlich nur ein wenig mehr Ordnung in unseren Monolithen bekommen und so unsere Sünden der letzten fünf bis zehn Jahre ungeschehen machen?

Mehr ist mehr

Wie also sieht eine Lösung aus, die uns einen Großteil der Vorteile von Microservices liefert? Vorteile, wie fachlich in sich geschlossene Module, unabhängige Skalierung, modulbasiertes Deployment, Austauschbarkeit von Diensten oder einfach nur der Mehrwert der verbesserten Wartbarkeit? Eine Lösung, die gleichzeitig aber deutlich weniger Komplexität für Management, Monitoring und Operations bedeutet? Die Antwort findet sich in dem Architekturprinzip der Self-contained Systems.

Schaut man sich einmal die, aus meiner Sicht extrem gut gelungene, Präsentation zum Thema SCS sowie die textuelle „Definition“ an, so positionieren sich Self-contained Systems, kurz SCS, irgendwo zwischen Monolithen und Microservices.

„The Self-contained System (SCS) approach is an architecture that focuses on a separation of the functionality into many independent systems, making the complete logical system a collaboration of many smaller software systems. This avoids the problem of large monoliths that grow constantly and eventually become unmaintainable. Over the past few years, we have seen its benefits in many mid-sized and large-scale projects.“

Was aber genau zeichnet einen SCS aus und wie unterscheidet er sich von einem Microservice? Der Begriff System – vs. Service – legt schon nahe, dass es sich irgendwie um etwas Größeres handelt, das gleichzeitig mehr oder minder autonom ist. Genau das findet man auch in der Auflistung der wesentlichen SCS-Charakteristika wieder, hier als Ausschnitt:

  • Jedes SCS ist eine autonome Webanwendung, die für Ihre Domäne alle Daten, die Logik, diese Daten zu bearbeiten, und den Code zum Rendern des Webinterface beinhaltet. Ein SCS kann seinen primären Use Case unabhängig von anderen Systemen abarbeiten.
  • Ein SCS gehört einem Team.
  • Die Kommunikation mit anderen SCSs oder Drittsystemen erfolgt, wenn möglich, asynchron. Ein SCS sollte auch dann noch funktionieren, wenn andere SCSs offline sind.
  • Ein SCS kann über ein Service-API verfügen. Auch wenn die Kommunikation mit dem User über das eigene Web-UI erfolgt, kann das Service-API für andere SCSs oder Clients hilfreich sein.
  • Ein SCS enthält Daten und Logik (siehe auch erstes Charakteristikum). Nur so ist es möglich, dass ein SCS unabhängig von anderen SCSs agieren kann.
  • Die Funktionalität eines SCS sollte End-Usern via eigenem Web-UI zur Verfügung gestellt werden. Funktionalität anderer SCSs kann verlinkt werden.
  • Enge Kopplung zu anderen SCS durch gemeinsam verwendeten Businesscode sollte vermieden werden.

DevOps Docker Camp

Teilnehmer lernen die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Schritt für Schritt bauen sie eine eigene Infrastruktur für und mit Docker auf.

Alle Termine des DevOps Docker Camps 2018 in der Übersicht

München: 19. – 21. Februar 2018
Berlin: 14. – 16. März 2018

SCS vs. Microservices

So wie es aussieht, haben SCSs und Microservices eine ganze Menge gemein. Die beiden Ansätze zeichnen sich insbesondere durch unabhängig zu deployende Einheiten aus, deren architektonische Grenzen sich auch in den verantwortlichen Teams widerspiegeln – Conway’s Law lässt grüßen.

Wo aber liegt nun der Unterschied der beiden Ansätze? Ein Microservice ist in der Regel kleiner als ein SCS. Wir reden also zum Beispiel nicht über einen Service der Granularität einer Adressvalidierung, sondern eher über ein Customer-Management- oder Billing-System eines Onlineshops. Als logische Konsequenz daraus besteht die resultierende Anwendung aus deutlich weniger Services – sorry, ich meinte Systemen – als in der Microservice-Welt.

Ein weiterer, wesentlicher Unterschied ergibt sich aus dem Anspruch, dass ein SCS seine fachliche Logik zum größten Teil ohne Kommunikation mit anderen SCS oder Drittsystemen ausführen kann. Dies gilt insbesondere für den primären Use Case des SCS. Diese strikte Forderung finden wir bei den Microservices nicht. Sie wäre aufgrund des feingranularen Aufbaus auch nicht besonders realitätsnah. Stattdessen gibt es für Microservices eigene Patterns zum Aggregieren.

Auch auf Seiten des visuellen User Interface findet sich ein Unterschied. Während es bei Microservices zwar möglich, aber eher unüblich ist, dass ein Service sein eigenes UI rendert und an den Client ausliefert, ist dies bei den SCS der Standard. Die Integration von verschiedenen SCS findet also vorzugsweise auf dem UI-Layer statt, bei Microservices dagegen eher auf dem Business Logic Layer.

Fazit

Bitte nicht falsch verstehen: Microservices ergeben durchaus Sinn und funktionieren nachweislich, wie Netflix, Amazon, aber auch deutlich kleinere Anwendungen uns erfolgreich demonstrieren. Um erfolgreich zu sein, muss aber auch eine gewisse Konsequenz an den Tag gelegt werden. Und spätestens hier scheitert es bei den meisten Unternehmen alleine schon aus organisatorischen Gründen.

Der Architekturansatz der SCS scheint da ein sehr guter Kompromiss zu sein, da der Fokus vor allem darauf liegt, große, nicht mehr zu handhabende Projekte so in überschaubare Teile aufzuteilen, dass diese einzelnen Teile von fachlich orientierten Teams unabhängig voneinander erfolgreich umgesetzt werden können. Microservices dagegen zielen eher auf eine erhöhte Flexibilität ab, um so zum Beispiel robustere und fehlertolerantere Systeme zu schaffen oder einzelne, stark frequentierte Services unabhängig skalieren zu können.

Schaut man sich einmal den einen oder anderen Blog zum Thema Microservices und die dort vorgestellten fachlichen Beispielservices an, so kann man sich des Eindrucks nicht erwehren, dass SCS am Ende das sind, was einige von uns bisher unter dem Begriff Microservices verstanden haben oder gerne verstehen wollten. SCS sind auf jeden Fall ein sehr interessanter Architekturansatz, den man im Blick behalten sollte! In diesem Sinne: Stay tuned!

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare
  1. DerNikolaus2016-05-02 09:49:21

    Sind die SCS Bootcamps und die SCS Summit Konferenzen schon geplant ;-)

  2. Joachim Arrasz2016-05-30 09:55:10

    Schöner Artikel, was mir aber (bei allen Artikeln in Richtung self contained systems) einfach nicht klar sein ist, warum reden denn alle von WEB Anwendungen ? Das ist imho eine Option von einigen.
    Warum also Webanwendung?

  3. Eberhard Wolff2016-05-31 20:56:25

    Hi Joachim,
    SCS sind schlicht als Web-Anwendungen definiert :-) http://scs-architecture.org/ nennt es gleich als erste Eigenschaft. Durch diesen Fokus umfasst der Architektur-Ansatz auch die UI und damit die komplette Fachlichkeit. Eine fachliche Änderung sollte nur ein SCS betreffen - inklusive UI. Klärt es das?
    Bis dann,
    Eberhard

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.