© istockphoto.com/FrankRamspott
Aktuelle deutsche E-Commerce-Microservices-Systeme vs. klassische E-Commerce-Systeme

Alt vs. Neu?


Microservices sind das Buzzword der Stunde. Was für die allgemeine Entwicklerlandschaft gilt, hält natürlich auch in spezialisierten Bereichen Einzug – wie in unserem Fall im E-Commerce. Ich will diese Gelegenheit nutzen, um das Szenario kritisch zu beleuchten.

Aktuell existieren im E-Commerce-Bereich einige Systeme, die versprechen, mithilfe eines Microservices-Architekturansatzes für Großkunden bessere, langlebigere Shops hochwertiger und schneller entwickeln zu können als das mit den klassischen E-Commerce-Systemen wie OXID, Magento oder Shopware möglich wäre. Die Anbieter der auf Microservices-Architekturansätzen basierenden Systeme meinen (ein fast wörtliches Zitat): Wenn ein Kunde eine Applikation braucht, für die nur Templateänderungen am Basisshop notwendig sind, dann sollte er die klassischen Systeme verwenden, ansonsten ein Microservices-E-Commerce-System. Um diese Überlegenheit zu begründen, führen sie verschiedene Argumente ins Feld.

Aber ist diese Überlegenheit tatsächlich gegeben? Zumindest zum aktuellen Zeitpunkt? Oder handelt es sich zu einem großen Teil um bloßen Hype? Denn der Microservices-Ansatz mag für jeden, der schon einmal etwas von Kapselung und Domain-driven Design gehört hat, charmant erscheinen, er birgt in der Umsetzung jedoch gewisse Tücken. Zum anderen sollte man sich fragen, welche Argumente der E-Commerce-Microservices-Vertreter tatsächlich direkt etwas mit dem Architekturansatz zu tun haben. Und könnten sie nicht genauso gut von jedem anderen professionell arbeitenden Entwicklungsteam angeführt werden?

Es geht in diesem Artikel darum, die Argumente der E-Commerce-Microservices-Vertreter kritisch zu hinterfragen und weitere ins Spiel zu bringen, mit dem Ziel, die für meinen Geschmack bislang etwas einseitig geführte Diskussion „E-Commerce-Microservices versus klassische E-Commerce-Systeme“ ein wenig zu beleben und auszugleichen.

Wenn ich im Folgenden des Öfteren OXID als Beispiel eines klassischen Systems nenne, bitte ich das dadurch zu entschuldigen, dass ich, weil ich bei OXID arbeite, hier mehr oder weniger weiß, wovon ich spreche.

Was sind Microservices eigentlich?

Ein Microservice kapselt üblicherweise einen bestimmten Applikationsbereich aus Businesssicht. Mögliche Beispiele dafür sind eine Artikelverwaltung, Logistik, Preiskalkulation oder der Check-out. Microservices sind daher meist nicht „Micro“, sondern eher „Macro“.

Jeder Service sollte seine eigenen Daten selbst verwalten, möglicherweise sogar in einer eigenen dedizierten Datenbank. Ein Service ist dabei oft eine eigenständige Applikation. Services können im Prinzip auf verschiedene Server verteilt werden. Es könnte auch zu einem Servicetyp (z. B. Check-out) mehrere Instanzen des Service in einem Produktivsystem geben, um die Last besser zu verteilen. Services kommunizieren üblicherweise asynchron über REST HTTP Requests miteinander.

Klassische E-Commerce-Systeme

Ein klassisches E-Commerce-System stellt sich üblicherweise grob wie folgt dar:

  • Eine Basisapplikation stellt einen fast vollständigen Onlineshop zur Verfügung. Diese Basisapplikation bietet vielfältige Konfigurationsmöglichkeiten an.

  • Für eine Kundenapplikation kann diese Basisapplikation zudem um Funktionalität angereichert werden, indem Plug-ins/Extensions eingebunden werden.

  • Daten werden meist in eine einzige Datenbank geschrieben.

  • Ein eingehender Request wird, bis auf die Kommunikation mit Fremdsystemen wie ERPs, normalerweise vollständig in der E-Commerce-Applikation abgearbeitet. Asynchrone Kommunikation bildet die Ausnahme.

  • Skaliert wird auf Applikationsebene größtenteils dadurch, dass eine weitere Instanz der Gesamtapplikation gestartet wird. Auf Datenbankebene kommen zu Skalierungszwecken Master/Slave-Szenarien oder High-Availability-Datenbankcluster zum Einsatz.

  • Die Anbieter der klassischen E-Commerce-Systeme bieten die Basisapplikation meist in verschiedenen Ausbaustufen (Editionen) an.

Argumente der aktuellen deutschen E-Commerce-Microservices-Systeme

Im Folgenden eine Liste von Argumenten von Repräsentanten einiger E-Commerce-Microservices-Systeme, die ich gehört oder von denen ich gelesen habe. Ich gebe hier keine Quellen an, man kann sie leicht überall im Netz finden.

Pro Microservices

  • Microservices-Architektur ist der Weg für die Zukunft

  • Upgrades sind einfach

  • Hochprofessionelle Teams setzen hochqualitative Projekte um

    • Wir haben einen Baukasten von Basisfunktionalitäten, der für ein Projekt einfach erweitert werden kann. Oft werden ca. 60 Prozent für ein Projekt neu geschrieben (Eigenaussage)

    • Die Einarbeitung von Entwicklern ist leicht

    • Continuous Integration/Delivery ist einfach

  • Microservices kann man einfach verteilen (verschiedene Instanzen eines Microservice auf verschiedene Server)

  • Gekapselte Microservices mit Kommunikation über HTTP-REST-APIs

  • Wir sichern eine Responsezeit von 50 ms/100 ms zu

Kontra klassische E-Commerce-Systeme: Im Prinzip kann man die Argumente der Microservices-Systeme gegen die klassischen E-Commerce-Systeme dadurch zusammenfassen, dass man alle im letzten Abschnitt getroffenen Positivaussagen negiert.

Untersuchung der Argumente

Da wir die Argumente nun kennen, ist es an der Zeit, sie genauer zu betrachten.

Microservices-Architektur ist der Weg für die Zukunft: Hier gibt es durchaus kontroverse Meinungen. Eine der für die Entwicklergemeinschaft am prominentesten ist die von Martin Fowler [1] mit dem zart optimistischen, aber doch eher zurückhaltenden Fazit (leicht paraphrasiert): „Schau mer mal“.

Upgrades sind einfach: Echte Projektupgrades sind nie einfach – wer so etwas behauptet, betreibt Augenwischerei.

Denn es wird hier kein Standalone-Produkt auf einer einzelnen Maschine geupgradet, sondern ein Projekt, das ein Konglomerat aus verschiedensten Bausteinen ist, das auch noch mit externen Systemen kommuniziert und in komplexen Serverlandschaften lebt. Wer nur einmal seinen Rechner auf eine neue Windows-Version gehoben hat, weiß, dass selbst eine neue Version eines „echten Produkts“, hinter dem ein so großes Unternehmen wie Microsoft steht, gewisse Schwierigkeiten bereiten kann.

Als echtes Upgrade sehe ich ein Major Release eines Service aus dem Baukastensystem, ein Major Release eines Projektservice, eine Änderung der Anbindung an ein externes System aufgrund einer Änderung des API des externen Systems oder die Anbindung eines neuen externen Systems.

Jede dieser Änderungen zieht einen Rattenschwanz an notwendigen Aufgaben nach sich, die Zeit kosten – egal welchen Architekturansatz man wählt.

Hochprofessionelle Teams setzen hochqualitative Projekte um: Im Prinzip richtig – sogar fast eine Tautologie –, mit den kleinen, aber wichtigen Einschränkungen: Wenn das Entwicklungsteam genug Zeit bekommt, eine ausgezeichnete Anforderungsanalyse gemacht wird und permanent Kundenfeedback in die Entwicklung einfließt. Was heißt das in Bezug auf die aktuellen deutschen E-Commerce-Microservices-Systeme?

Wir haben einen Baukasten von Basisfunktionalitäten, der für ein Projekt einfach erweitert werden kann: Laut eigenen Aussagen der E-Commerce-Microservices-Vertreter wird bei den in Frage kommenden Projekten der Großteil des Codes neu für den Kunden entwickelt. Die Anforderungsanalyse betrifft daher nicht nur allen Bestandscode des Baukastens, der angepasst/konfiguriert werden muss, sondern auch den Löwenanteil an Neuentwicklung.

Die Qualität der Anforderungsanalyse hängt allerdings nicht nur vom Umsetzer ab, sondern zu großen Teilen vom Kunden selbst. Er muss durchgehend qualifizierte Ansprechpartner für die Mitarbeit an den Anforderungen und für Feedback zu Projektinkrementen bereitstellen. Das wird meiner Erfahrung nach in der Praxis allerdings oft nicht der Fall sein.

Hat man die Anforderungen, muss man entwickeln. Nun ist neu entwickelter Code per Definition noch nicht markterprobt und birgt ein gehöriges Risiko. Dieses Risiko wird dadurch verschärft, dass es sich bei den Projekten (wieder...

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