Monolith oder Microservices im E-Commerce?

„Wir entwickeln nur noch Microservices.“ – Diese Aussage ist mir in meiner E-Commerce-Erfahrung  schon öfter über den Weg gelaufen. Nach der Prüfung mit dem Kunden stellte sich nur in wenigen Fällen ein Mehrwert der Microservice-Struktur heraus.

Die Begriffe kurz erklärt:

Microservice: Eine Software-Anwendung wird in kleine Teile (Services) gespalten. Jeder Service hat eine spezifische Aufgabe und läuft voneinander unabhängig. Über sprachunabhängige Schnittstellen erfolgt die Kommunikation der Services untereinander.

Monolith: Eine homogene, nicht teilbare Software-Anwendung realisiert die Anforderungen    . Ein neuer Impuls ist dabei der modulare Monolith. Neben einem festen Core für Basisfunktionalitäten gibt es austauschbare Module, die im Gegensatz zu Microservices aber untereinander feste Abhängigkeiten haben können.

Interessenskonflikte – vor, während und nach der Entwicklung 

Im Entwicklungsprozess eines E-Commerce Projektes treffen verschiedene Interessen  aufeinander. Dies wären die Softwareentwickler, die Projektmanager und die IT/Hoster.

In manchen Projekten wird zudem die Position eines Product-Owners besetzt, dieser vertritt die Interessen der Stakeholder und dient als Kommunikationsschnittstelle zwischen ihnen und dem Entwicklungs-Team. Für diesen Artikel möchte ich aber den Product-Owner außen vor lassen.

Der Softwareentwickler setzt die Akzeptanzkriterien um und die gegebenen User Stories zu erfüllen , dabei hat er Wartbarkeit und Erweiterbarkeit zu berücksichtigen. Ein Projektmanager kümmert sich um die Projektumsetzung in Scope, Time und Budget. Dabei sind ihm Planungssicherheit, Auslastung der Entwickler und klare Zuständigkeiten wichtig. Die IT/Der Hoster möchte eine möglichst hohe Uptime garantieren und Skalierbarkeit bei Lastspitzen ermöglichen.

Vor- und Nachteile der Architekturen für die Interessensgruppen

Softwareentwickler

Die Microservice-Struktur ist fachlich anspruchsvoller sowie kommunikations- und dokumentationsintensiver. Hier hat ein erfahrenes, gut eingespieltes Team mit manifestierten Vorgängen einen deutlichen Vorteil.

Dank der technologischen Unabhängigkeit von Microservices können die Entwickler sich für eine Programmiersprache entscheiden, mit der sie am meisten Erfahrung haben und welche am besten für die Anforderungen geeignet ist.

Auch hilft die Struktur bei der Code-Qualität. Durch die Teilung in Services ist es nicht möglich künstliche Abhängigkeiten versehentlich zu schaffen. Auch ist der Code aufgrund des geringeren Umfangs besser zu analysieren, zu warten und zu debuggen. Dies ist aber kein Alleinstellungsmerkmal für Microservices. Magento 2 fährt (noch) als Monolith bspw. auch einen modularen Ansatz mit Definitionen, wo welche Teile der Applikation zu finden sind. Jedoch ist man als Entwickler nicht daran gebunden und Zeitdruck bzw. fehlende Einarbeitung führen leider schneller zu Spaghetticodes als in einem Microservice. Dank der strikten Teilung bei Microservices kann man aber ähnliche Funktionalitäten zwischen den Microservices nicht Wiederverwenden und die Orchestrierung ist wesentlich komplexer.

Im Performancevergleich auf gleicher Hardware gewinnt der Monolith, da die zusätzliche Kommunikationsschicht zwischen den Services wegfällt.

Projektmanager

Für einen Projektmanager gibt es Für und Wider für die jeweiligen Architekturen. Während Microservices geregelte Zuständigkeiten und Zugriffsrechte ermöglichen, verhärten sich die Abhängigkeiten sowie der Kommunikationsaufwand. Vor allem wenn weitere Teams mit separaten Projektmanagern weitere Services umsetzen, die Abhängigkeiten untereinander haben. Hier steigt der Kommunikationsaufwand exponentiell. Dafür sind Schätzungen näher an der Realität, da die Code-Komplexität in kleinen Komponenten abnimmt, die Teams kleiner sind und skalierbar mit den Anforderungen des Microservices.

Monolithen haben dafür eine größere Chance historisch zu wachsen. Der Code kann überall wiederverwendet werden und eine Verbesserung von zu Grunde liegendem Code ist tückisch, da an unerwarteten Stellen Fehler auftreten können.

IT/Hoster

Hier spielt der Microservice-Ansatz seine wohl größte Stärke aus. Die Wahl zwischen vertikaler und horizontaler Skalierung. Bei vertikaler Skalierung wird bspw. der zugewiesene Arbeitsspeicher erhöht und/oder der Prozessor oder die Festplatten verbessert. Hier gibt es aber eine harte Grenze, was der Stand der Technik bzw. der Hoster zu dem Zeitpunkt ermöglichen kann. Horizontale Skalierung hingegen hat theoretisch keine Limitation. Ist gerade der Check Out ausgelastet? Ein zweiter Service kann gestartet werden. Hohe Ladezeiten bei der Registration nach einer Werbemaßnahme? Noch ein Service. Sobald sich das Verhalten wieder normalisiert hat, können redundante Services wieder gestoppt werden. Dies bedeutet, dass das Kundenerlebnis zu keinem Zeitpunkt unterbrochen wird und keine Umsatzausfälle stattfinden. Ein Monolith kann nicht vertikal Skalieren. 

Es ist aber möglich zweigleisig zu fahren und die Vorteile beider Architekturen zu nutzen, indem man bspw. den Checkoutprozess in einen Service auslagert und der Rest von einem Monolithen übernommen wird. So könnte man initial mit einem Monolithen starten und sich das Onlinegeschäft aufbauen. Wenn sicher ist, dass die Webseite von Kunden gut angenommen wird und Umsatz erzeugt, lagert man Flaschenhälse in skalierbare Services aus.

Oft wird als Pro-Microservice-Argument genannt, dass ein Systemfehler, der zum Ausfall eines Microservices führt, nicht so kritisch für das Gesamtsystem sei.  Ein Shop ohne Produkte bzw. Bezahlfunktion ist in der Realität aber auch nicht viel besser als ein Totalausfall.

Fazit

Die Entscheidung für eine Microservice-Architektur sollte nicht nur in der E-Commerce Welt leichtfertig getroffen werden.

Im Allgemeinen sind die größten Vorteile von Microservices gegenüber Monolithen, die Skalierbarkeit der Applikation sowie des jeweiligen Entwickler-Teams und deren Wartbarkeit und Anpassbarkeit. Dies folgt aber auf Kosten von erhöhter Komplexität, potenzieller Technologievielfalt und fehlende Wiederverwendbarkeit zwischen den Services. 

Im E-Commerce sollten folgende Punkte erfüllt sein:

• Hoher erwarteter Umsatz
• Erwartung einer hohen Laufzeit
• Bestehender Kundenstamm
• Funktionalität bei kritischen Lastspitzen wichtig
• Erwartungsmanagement bzgl. Budget und Entwicklungszeit

Wird ein Onlineshop erstmalig aufgebaut, ist es aufgrund des Kosten-Nutzen-Verhältnis ratsam mit einem Monolithen zu starten und über die Zeit erkennbare Bottlenecks in Microservices auszulagern.

Wenn man ein hohes Auftragsvolumen über den Webshop erwartet und große Lastspitzen wie bspw. durch geschaltete Fernsehwerbung oder Sale-Events möglich sind, sollte man die Microservice Architektur anstreben.