© StonePictures/Shutterstock.com
Müssen es immer Microservices sein? Die Wahl der richtigen Architektur

Kolumne: EnterpriseTales


Microservices waren in den letzten Jahren ein echtes Hypethema. Doch vielerorts setzt nach der ersten Euphorie nun langsam Ernüchterung ein. Zeit für mich, einmal einen unvoreingenommenen Blick auf die Wahl der richtigen Architektur zu werfen.

Architekturtrends scheinen sich wie so vieles in Wellenbewegungen zu entwickeln. Um die Jahrtausendwende war SOA (Service-oriented Architecture) der Architekturtrend schlechthin. Bereits ein paar Jahre später merkte man, dass der gewählte Ansatz große Nachteile hatte: Systeme, die zur Entwicklung entkoppelt waren, mussten zur Laufzeit dennoch zusammenspielen. Schnittstellenänderungen mussten immer an zwei Systemen (Aufrufer und Aufgerufener) implementiert werden. Der Versuch, das Problem mit einem Enterprise Service Bus zu entschärfen, scheiterte, weil weiterhin zwei Systeme angefasst werden mussten (diesmal Aufgerufener und ESB).

Da war es doch deutlich leichter, gleich alles in eine Deployment-Einheit zu packen – es entstanden monolithische Applikationen. Irgendwann wurden diese allerdings so groß, dass sie für die Teams nicht mehr beherrschbar waren. Die Folge war, dass scheinbar kleine Änderungen unverhältnismäßig lange brauchten, bis sie umgesetzt waren. Getrieben durch Netflix, Amazon und Co. kam der Trend der Microservices auf, der kleine Änderungszyklen versprach.

Schwergewichtige Monolithen

Aber was genau hindert die Entwickler eigentlich daran, auch in den alten Monolithen neue Features schnell in Produktion zu bringen? Meistens sind es die so viel zitierten „historisch gewachsenen“ Strukturen. Diese manifestieren sich in unleserlichem Spaghetticode mit nicht nachvollziehbaren Aufrufketten. Dazu kommt der Mangel an automatisierten Tests.

Bei Monolithen, die im ersten Jahrzehnt dieses Jahrtausends entstanden sind, wurde häufig ein großer Fokus auf die Schichtenarchitektur gelegt. Die Einhaltung dieser Architektur war in der Regel wichtiger, als auf den fachlichen Schnitt zu achten.

Wenn es überhaupt fachliche Module gab, bezogen sich diese häufig auf Domänenobjekte und nicht auf Use Cases. Das hat(te) zur Folge, dass an einzelnen Use Cases (häufig sogar an einzelnen Requests) mehrere Module beteiligt waren (nämlich alle Module der beteiligten Domänenobjekte). Das Ergebnis war ein unübersichtlicher Codefluss durch die Module und hohe Abhängigkeiten zwischen den Modulen.

Ein Entwickler konnte dann nicht mehr genau abschätzen, was seine Codeänderung tatsächlich für Auswirkungen auf die beteiligten Module hat. Fehlende automatisierte Tests taten ihr Übriges. Nach jeder noch so kleinen Änderung musste eigentlich die gesamte Anwendung auf unerkannte Seiteneffekte überprüft werden. Mehrwöchige Testphasen vor einem Release waren die Folge, was im Ergebnis zu maximal zwei bis vier Releases pro Jahr führte. Viele der so aufgebauten Monolithen existieren heute noch. Allein die Tatsache der seltenen Releases führt dazu, dass ein Feature verhältnismäßig lange braucht, um in Produktion zu gelangen. Dazu kommen der höhere Entwicklungs- und Testaufwand.

Darüber hinaus erfordert der ungünstige Modulschnitt bei jeder Änderung einen hohen Abstimmungsaufwand zwischen verschiedenen Teams. Das erhöht natürlich die Entwicklungszeit eines Features weiter.

Kleinere Änderungszyklen

Aber was ist an Microservices anders? Warum ist es mit ihnen schneller möglich, Features in Produktion zu bringen?

Da ist zunächst einmal der Schnitt. Microservices sind grundsätzlich vertikal nach Use Cases geschnitten. Die Realisierung eines „normalen“ Features betrifft dann in der Regel nur einen Microservice. Allein dieser Unterschied zu den Monolithen sorgt schon dafür, dass die meisten der oben genannten Probleme der Monolithen nicht mehr vorhanden sind: Da ein Microservice verhältnismäßig klein ist, ist der Code überschaubar und die Seiteneffekte eines Features sind abschätzbar. Zudem ist es bei einer so kleinen Codebasis einfacher, die Testabdeckung hochzuhalten. Abstimmung zwischen verschiedenen Teams fällt häufig...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang