Mikrosystems vs. Mikroservices

Der Begriff Mikroservice ist IN. Nicht ohne Grund. Erfahrungen der letzen 10 Jahre, insbesondere mit großen Webanwendungen, haben dem Mikroservicegedanken den Boden bereitet. Zu große Anwendungen, zu komplizierte und seltene Deployments, unklare Verantwortlichkeiten dienen in der Diskussion als Begründung des neuen Architekturstils. Am Begriff Mikroservice haben sich einige Kontroversen entzündet. Mikroservice vs. Monolith: An die Stelle einer großen Anwendung, die als ganze deployt wird, treten viele kleine Services, die als deploybare Einheiten eine Anwendung in Fachlichkeiten dekomponieren. Mikroservice vs. Nanoservice: Wie viele Zeilen Code soll ein Service enthalten? 100? Ist die Frage sinnvoll – unabhängig von Programmiersprache und Kontext? Vielleicht ist sie nur Symptom der Frage: Wie weit kann und soll man die Mikrofizierung treiben?

Eine Differenz im Streit um die Mikroservices scheint mir neu zu sein. Während die Frage des Monolithen sich mit der Vergangenheit großer Systeme beschäftigt und die Suche nach der intrinsischen Grenze von Mikroservices (eben Nanoservices) eine Idee an ihre (syntaktische) Grenze treibt, ist die Kontroverse Mikroservice vs. Mikrosystem neu auf meinem Radar.

Worum geht es. Stefan Tilkov beschreibt es provokativ in der Software Engineering Radio Episode 210 so: Der Begriff Mikroservice beschreibe eigentlich nur den alten SOA-Gedanken mit neuen Worten. Ein neuer Ansatz entstehe erst, wenn der Mikroservice mit einem UI und einer Datenbank, also Zustand, versehen werde. Und das sei dann kein Service sondern ein System. Das nennt er dann Self-contained System.

Eine der Erfahrungen, die Stefan Tilkov hier verarbeitet, ist der Bau des neuen otto.de-Webshops, der auf den Projektnamen ‘Lhotse’ hört. Auf der QCon in London haben er und Oliver Wegner von Otto dessen Architektur vorgestellt. Der neue Webshop besteht aus separaten Systemen: ‘System architecture is vertical’. Jedes System bildet eine Phase der Aktivität eines Benutzers im Shop ab: Discover, Search, Assess, Order, Check. Jedes System hat ein UI und eine eigene Persistenz. Die Integration der Systeme erfolgt so spät wie möglich – im Browser oder im Webcache (als Edge-Side-Include). (Mehr zur Lhotse-Architektur findet sich hier

Ich finde die Differenz, die Stefan Tilkov hier macht und die meines Wissens noch keine Wellen geschlagen hat, sehr spannend. Zunächst scheint es als ob nur über eine zusätzliche Schicht gesprochen wird – soll der Service, besser: das System, ein UI haben oder nicht. Damit steht und fällt aber eine andere Entscheidung. Ist das System für den Kunden sichtbar oder ist es ein ‘internes System’? Wenn es für die Kunden sichtbar ist, kann das Team, das für das System zuständig ist, sein System an Kennzahlen und Tests mit echten Kunden im echten Betrieb optimieren. Wenn er – jetzt ist es ein Service – kein UI hat, gibt es noch mindestens eine andere Komponente, die seine Inhalte dem User präsentiert oder seine Inhalte mit den Inhalten anderer Services kombiniert und diese Mixtur an den User weiterreicht. Die Kundenorientierung des Teams, welches den Services entwickelt, ist höchstens eine mittelbare.

Die Unterscheidung, die Stefan Tilkov macht, lässt sich als: Ist das System für den Kunden sichtbar oder nicht reformulieren. Sein Standpunkt lautet: Jedes System muss bis zum Kunden reichen. Das ist zumindest für Webshops – die einzige Domäne mit der ich mich auskenne – eine Forderung mit Sprengkraft. Jeder Webshop – egal ob Monolith oder Schwarm von Services – spricht, um seine Arbeit zu verrichten, mit einer Vielzahl anderer Systeme: Logistiksysteme (Bestellungen abwickeln), Content-Datenbanken (Informationen über Artikel), Mediendatenbanken, (Bilder bereitstellen), Kundensysteme. All diese internen Systeme haben keine ‘wirklichen’ sondern ‘nur’ interne Kunden: der Webshop ist ihr interner Kunde, über ein Administrationsinterface haben sie oftmals interne Mitarbeiter als Kunden. Erfolg solcher internen Systeme zu messen, Metriken zu haben, die ‘in letzter Instanz’ dann auch mit echtem Kundenerfolg verbunden sind, ist für solche internen Systeme schwer und oftmals führen sie ein Eigenleben, welches nur sehr mittelbar mit den Anforderungen der ‘wirklichen’ Kunden verbunden ist.

Bläst man die kleine Differenz – Service vs. System – auf zu einem Paradigma: Jedes System muss ein UI haben und für ‘echte’ Kunden sichtbar sein, jedes Team braucht echte Kunden, um seinen Erfolg zu messen, taugt es als Richtschnur für die Restrukturierung einer ganzen Firmen-IT. An die Stelle von breiten Systemen, die eine Fachlichkeit in jeder Hinsicht kapseln, treten vertikale geschnittene Systeme, die in einer Hinsicht Fachlichkeiten integrieren und die bis zum UI reichen.

Was das heisst, ob das geht, welche Erfahrungen es schon gibt, könnte der Inhalt eines anderen Beitrages sein. Mir reicht es im Moment, mich am Knistern dieser elektrisierenden Differenz zu wärmen und die Funken, die sie schlägt, in Bilder zu übersetzen.