Microservices im E-Commerce

Während es früher im Onlinehandel nur den Pc und Netbooks als Touchpoint gab, erwarten die Kunden heute und in Zukunft – immer von überall und von jedem Device - einkaufen zu können. Um dieses Ziel zu erreichen, müssen Shop-Anwendungen immer mehr Anwendungsfälle abbilden. Werden all diese Anforderungen in einer einzigen monolithischen Anwendung Umgesetzt, entstehen in den kommenden Jahren weitreichende Probleme. Es steigen die Kosten für Skalierung, Wartung und Feature-Implementierung.

Womit sich die Frage stellt, ob Microservices als Ergänzung zu einer monolithischen Anwendung von Vorteil sind.

Größte Unterschied zum klassischen Ansatz einer monolithischen Anwendung, wo die einzelnen Komponenten nur im Source-Code von einander getrennt und nach dem Deployment eine große Anwendung bilden, werden beim Micro-Service-Ansatz die einzelnen Komponenten auf viele  Anwendungen – eben Microservices - aufgeteilt. Wodurch jeder Microservice jeweils seine eigene Laufzeitumgebung inne hält und unabhängig deployed werden kann. Wobei ein Microservice - wie der Name schon vermuten lässt – vom Umfang möglichst klein und überschaubar gehalten werden sollte. Mit dem Umstand, dass Microservices als eigenständige Anwendung betrieben werden, ist die Kommunikation ein zentrales Thema bei der Entwicklung der Makro-Architektur. Oft wird zur Kommunikation REST verwendet.

Ein Klassiker – der als erstes in den Sinn kommt - ist wohl die Anbindung eines Payment-Service-Providers. Wie beispielsweise Wirecard. Oft müssen aber auch andere Drittsysteme angebunden werden. Vor allem im Cross-Channel Bereich interagiert ein Shop-System mit verschiedensten Diensten und Plattformen. Zum Beispiel Newsletter-Tools, Display-Advertising-Plattformen, Warenwirtschaftssystemen und viele weitere. Für solche Anwendungsfälle stellt Shopware eine REST Api zur verfügung.

Eines der häufigsten Szenarien ist dabei der Import von Daten. Dabei erfolgt beim Import meist eine Transformation der gegebenen Datenstruktur. Nehmen wir zum Beispiel den Import von Produktdaten aus einem Warenwirtschaftssystem – abgekürzt WWS - wie openZ oder Pickware. Das WWS liefert für den Import zwar die Produktdaten und Produktbilder aber es fehlen die verschiedenen Produkt-Kategorien, in welche das jeweils zu Importierende Produkt zuzuordnen wäre. Nun kann dieses Problem auf verschiedenste Weisen gelöst werden. Wir Pflegen die fehlenden Daten nach dem Import über das Shopware Backend ein; welches für kleinere Datenmengen potenziell die günstigste Lösung ist. Doch was tun, wenn Abertausende von Produktdaten ins Shop-System importiert werden müssen? Eine Lösung ist, diesen Vorgang mit einem Micro-Service zu automatisieren.

Bei der Entwicklung eines Microservice haben sich zwei Ansätze zur Schaffung abgezeichnet: Code-First- und Contract-First-Entwicklung. Damit geht einher, das beim zuletzt genannten Ansatz die Schnittstelle des Microservice - noch vor der Implementierung des eigentlichen Services - definiert wird.

Nach dem Contract-First-Ansatz wird über www.editor.swagger.io die API Schnittstelle definiert. Die swagger.json Datei zeigt eine Beispiel-Definition für den Categoryfinder Microservice. So kann über eine POST-Anfrage ein Produkt mit Titel und Beschreibung übergeben werden und erhält im Anschluss die passenden Kategorien. Nun lassen sich mit der Schnittstellenbeschreibung schon mal Server-Stubs für den zukünftigen Microservice erstellen. Welche somit in Continous-Integration-Pipelines für das automatisierte Testen direkt zur Verfügung stehen. Darauf folgt dann – wie schon bereits erwähnt – die eigentliche Implementierung der Geschäftslogik. Für die Klassifizierung der Produkte bietet sich ein durch Machine-Learning trainiertes Tensorflow-Model an. Dabei liefert das Tensorflow-Model - vereinfacht beschrieben - für jede Kategorie einen Wert der Aussagt: wie wahrscheinlich das Produkt dieser Kategorie angehört. Für alle Kategorien die eine hohen Wert besitzen gibt der Micro-Service dann die entsprechende Id und den Namen der Kategorie - wie im zuvor erstellten Vertrag definiert - als Response zurück. Und ergänzt so die Fehlenden Produktinformationen.

Micro-Services bieten durch das unabhängige Deployment und die freie Technologiewahl gute Voraussetzungen dem Kunden kontinuierlich neue Features zur Verfügung zu stellen. Nicht nur in einer Micro-Service-Architektur. Sondern auch als Ergänzung zu bestehenden und neuen Monolith-Anwendungen. Dabei ist der Contract-First-Ansatz eine gute Methode, um Microservices zu Entwickeln und bereit zu stellen; wobei das Tolerant-Reader-Pattern beachtet werden sollte. Welches besagt, dass nur die Felder und Exceptions definiert bzw. verarbeitetet werden, die auch wirklich für den Anwendungsfall nötig sind. Die innere Aufteilung des Micro-Service in Struktur und Verhalten – statt nach Domain Driven Design – trägt zusätzlich zur Vereinfachung und Übersicht bei.