Monolithen nicht grundsätzlich aufbrechen

Microservices einführen oder nicht?

| Autor / Redakteur: Dr. Rebecca Parsons * / Stephan Augsten

Ob eine monolithische Anwendung in viele kleine Microservices aufgesplittet werden sollte, ist eine Einzefallentscheidung.
Ob eine monolithische Anwendung in viele kleine Microservices aufgesplittet werden sollte, ist eine Einzefallentscheidung. (Bild: qimono - Pixabay.com / CC0)

Microservices spielen inzwischen bei vielen Unternehmen eine wichtige Rolle. Die Aufsplittung von Anwendungen aber noch nicht uneingeschränkt zu empfehlen, heißt es im ThoughtWorks Technology Radar. Die Gründe wollen wir hier diskutieren.

Besonderen Auftrieb erfuhr die Bewegung hin zu Microservice-Architekturen durch den wegweisenden Artikel von James Lewis und Martin Fowler, das Buch „Building Microservices“ von Sam Newman sowie zahlreiche Talks und Artikel von ThoughtWorks, Netflix, Google und vielen anderen.

Microservices wurden schnell in den Trial-Kreis des ThoughtWorks Technology Radar aufgenommen, haben es aber nie in den Adopt-Kreis geschafft. Warum das so ist? Dem möchte ich heute nachgehen. Führen wir uns zunächst noch einmal vor Augen, wie Trial und Adopt auf dem Radar definiert sind.

Wenn eine Technologie in den Trial-Kreis aufgenommen wird, ist sie so ausgereift, dass Unternehmen in ihren eigenen Systemen mit ihr experimentieren können. Bei ThoughtWorks setzen wir eine solche Technologie bereits erfolgreich ein und halten sie für stabil. Außerdem wissen wir, wie und in welchem Rahmen sie funktioniert.

Verschieben wir eine Technologie in den Adopt-Kreis, hat diese Technologie unserer Ansicht nach in bestimmten Bereichen das Zeug zum Standard. Beispiel Datenbanken: Mit der Aufnahme von Neo4J als Graphdatenbank in Adopt wollen wir nicht dafür plädieren, alle Daten in Graphdatenbanken zu erfassen. Vielmehr haben wir durch die Platzierung ausgedrückt, dass wir Neo4J all jenen empfehlen, die eine Graphdatenbank verwenden möchten.

Bei Adopt liegt die Messlatte bewusst hoch

Warum haben wir also Microservices – oder Microservices-Architekturen – nicht in Adopt aufgenommen? Immerhin finden sie auf Konferenzen und in Veröffentlichungen als Thema große Beachtung. Immer mehr Unternehmen entscheiden sich für diesen Architekturstil – und auch ThoughtWorks-Teams haben Microservices schon bei vielen Projekten erfolgreich eingesetzt. Es gibt mehrere Gründe: Einige ergeben sich aus der Definition des Adopt-Kreises, andere aus den Microservices selbst. Ich beginne mit den Radar-spezifischen Punkten.

Eine Technologie in Adopt zu verschieben, ist ein gewichtiger Schritt. Wir sprechen damit eine klare Empfehlung aus. Adopt heißt: Wir sind überzeugt, dass die Entscheidung für diese Technologie im Rahmen leicht zu definierender Bedingungen richtig ist. Microservices bieten zwar deutliche Vorteile, sind aber auch mit Kosten verbunden.

Wie Unternehmen zwischen Kosten und Nutzen abwägen, ist unterschiedlich und hängt beispielsweise vom digitalen Reifegrad und der Domain ab, aber auch von anderen Faktoren, die sich auf die verfügbaren Entwicklungsressourcen auswirken könnten. So weit können wir bei unseren Adopt-Empfehlungen nicht gehen. Und selbst wenn wir es könnten, würde es doch nicht ganz dem entsprechen, wie wir darüber denken. Eine Empfehlung im Adopt-Kreis sollte eindeutig sein.

Noch wichtiger ist aber ein anderer Aspekt von Adopt: Was hier eingeordnet wird, sollte mehr oder weniger universell anwendbar sein – unabhängig vom digitalen Reifegrad unserer Kunden und der Unternehmen allgemein. So ist eine Technologie, die sich auf Startups, nicht aber auf größere Unternehmen anwenden lässt, nicht für Adopt geeignet.

Ein bekanntes Beispiel hierfür sind verteilte Versionskontrollsysteme, die sich in vielen Technologieunternehmen verbreiteten. Wir haben sie zunächst nicht in Adopt platziert, weil viele Unternehmen zu diesem Zeitpunkt noch ihre Schwierigkeiten mit einfacher Quelltextkontrolle hatten.

Unserer Ansicht nach war der Schritt zur verteilten Versionskontrolle für viele einfach zu groß, um eine Adopt-Empfehlung auszusprechen. Wir haben uns schlussendlich dafür entschieden, GitHub in Adopt zu verschieben, allerdings erst ein paar Jahre später.

Nicht alle Unternehmen sind bereit für Microservices

Die Hürden, die es zu überwinden gilt bevor Microservices angewendet werden können, sind zu groß, so dass wir Microservices nicht in Adopt aufgenommen haben. In einem Post zu Microservices erklärt Martin Fowler: Ein gewisser digitaler Reifegrad, z. B. im Hinblick auf Continuous Delivery und Infrastructure Automation ist erforderlich, damit Microservices überhaupt infrage kommen.

Bis dahin ist es für viele Unternehmen noch ein weiter Weg. Microservices erhöhen die Arbeitslast im operativen Betrieb, da mehr Dinge überwacht, gemeldet und implementiert werden müssen. Umfassende Automatisierung und kontinuierliche Bereitstellung sind in diesem Zusammenhang unumgänglich.

Darüber hinaus gibt es in einer Microservices-Architektur Fehlerquellen, die bei Monolithen nicht existieren. Microservices-Systeme sind in sich verteilt, und Geschäftsprozesse funktionieren meist nur durch das Zusammenspiel mehrerer Microservices.

In monolithischen Umgebungen werden Geschäftsprozesse in der Regel innerhalb einer Prozessgrenze ausgeführt, die traditionelle Transaktionen zulässt. Die Ausführung erfolgt entweder ganz oder gar nicht. Während wir für all diese Probleme Lösungen haben, führt der Microservices-Ansatz diese Probleme ein und erfordert den Umgang mit ihnen.

Es ist also eine (gängige) Abwägung zwischen der höheren Flexibilität von Microservices und der Einfachheit des monolithischen Ansatzes, vor allem wenn der Monolith gut strukturiert ist. Anwendungen, bei denen die Flexibilität keinen besonderen Nutzen mit sich bringt, sind eher keine Kandidaten für eine Microservices-Architektur.

Beim Design einer Microservices-Architektur gilt es, eine zentrale Entscheidung zu treffen, nämlich wo die Grenzen zwischen den Services liegen sollen. Kontextgrenzen geben zwar vor, wo die Grenzen der Anwendung sind, aber es gibt immer noch Auswahlmöglichkeiten, und eine falsche Entscheidung macht das System komplizierter.

Bei einer neuen Domain ist nicht unbedingt klar, wo sich die Grenzen tatsächlich befinden. Daher spricht einiges dafür, eine Microservices-Architektur erst einzuführen, wenn die Domain und ihr Kontext konkreter sind.

Microservices spielen in Unternehmen nach wie vor eine wichtige Rolle

Sie fragen sich jetzt vielleicht, wieso wir Microservices-Architekturen dennoch empfehlen. Der Microservices-Ansatz ist flexibel, unabhängig skalierbar, evolutionär wachsend und fördert eine klare Trennung von einzelnen Anwendungsgebieten. Dadurch bringt er nach wie vor erhebliche Vorteile mit sich, die an anderer Stelle bereits ausführlich beschrieben sind.

Wir möchten Microservice-Architekturen auf jeden Fall weiter verwenden, unser Wissen darüber ausbauen und uns auch in Zukunft mit Tools und Ansätzen beschäftigen, die Lösungen für die hier vorgebrachten Nachteile bieten.

Zhamak Dehghani von ThoughtWorks hat zudem kürzlich diesen Leitfaden zum Aufbrechen von Monolithen in Microservices veröffentlicht. In den Adopt-Kreis werden es Microservices aufgrund der Kosten und Nachteile sowie des erforderlichen digitalen Reifegrads aber wohl nie schaffen.

Dr. Rebecca Parsons
Dr. Rebecca Parsons (Bild: ThoughtWorks)

* Dr. Rebecca Parsons ist Chief Technology Officer bei der weltweit tätigen Technologieberatung ThoughtWorks. Sie hat viele Jahre Erfahrung in der Anwendungsentwicklung, in Branchen von Telekommunikation bis hin zu neuen Internetdiensten. Sie verfügt über umfangreiche Erfahrung in der Projektleitung beim Aufbau großer Anwendungen für verteilte Objekte und bei der Integration verteilter Systeme. Bevor sie zu ThoughtWorks kam, lehrte Rebecca Parsons als Assistenzprofessorin Informatik an der University of Central Florida.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45508260 / Microservices)