Ina El-Kadhi OXID eSales

Natürlich wirkt der Ansatz „Microservices“ auf Entwickler mit architektonischem Hintergrund ansprechend, weil er eine logische Weiterentwicklung von objektorientierten Kapselungsprinzipien zu sein scheint.

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 Business-sicht. 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. Diese eigenständigen Applikationen können im Prinzip auf verschiedene Server verteilt werden. Es könnte auch zu einem Servicetypen (z. B. Check-out) mehrere Instanzen des Services in einem Produktivsystem geben, um die Last besser zu verteilen. Services kommunizieren üblicherweise asynchron über REST HTTP Requests miteinander.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Entwickler Magazin 1.17 - "Microservices im E-Commerce"

Alle Infos zum Heft
579748953Microservice-E-Commerce Systeme oder doch eher klassisch?
X
- Gib Deinen Standort ein -
- or -