Service Mashup im E‑Commerce: Komplexe Systeme entflechten

Platine

Serviceorientierte Architekturen (SOA) sind heute Standard in E‑Commerce-Systemen. Erfahren Sie hier, was hinter Microservices & Co. steckt und wie die Umstellung von monolithischen auf servicebasierte Systeme gelingt.

Online-Händler stehen vor der Herausforderung, dass sich die Rahmenbedingungen für ihr E‑Commerce laufend verändern. Kunden ändern ihr Kaufverhalten, neue Technologien setzen neue Standards im Wettbewerb um die Gunst der Käufer. Mit jeder neuen Anforderung an den E‑Commerce, vergrößert sich automatisch die Komplexität von Systemen, Prozessen und Daten beim Händler.

Die Grenzen monolithischer Systeme

Systeme aus einem Guss, sogenannte monolithische Systeme, stoßen schnell an Grenzen, weil sie sich ab einer bestimmten Komplexität oft nicht mehr ohne Weiteres flexibel anpassen lassen. Der Klassiker: Ein Standard-System wird punktuell oder über einen längeren Zeitraum so sehr auf die den individuellen Bedarf eines Händlers angepasst, dass am Ende das System aus 20 % Standard- und 80 % individuellem Software-Code besteht. Ein solches System lässt sich, wenn überhaupt, nur mit sehr hohem Aufwand erweitern. Versions-Updates können im Einzelfall viele Manntage kosten, ohne dass dadurch viel Funktionalität bzw. Mehrwert gewonnen wird.

Servicesorientierte Architekturen schaffen Abhilfe

Aus diesem Grund teilt man heute vor allem komplexe Systeme in einzelne Programme und Aufgaben in serviceorientierte Architekturen auf. Besonders große Unternehmen mit komplexen Softwaresystemen, die laufend weiterentwickelt werden, setzen auf Services. Bei sehr kleinem Funktionsumfang spricht man von Microservices.

“Der eCommerce-Riese Amazon stellt alle 11,7 Sekunden neuen Code online. Ohne Microservices wäre das nicht möglich.”
Dirk Hörig, CEO Commercetools

Die Idee hinter serviceorientierten Architekturen findet sich schon in der UNIX-Philosophie:

  • Ein Programm soll nur eine Aufgabe erfüllen,
  • Programme sollen zusammenarbeiten können und
  • sie sollen dafür Standard-Schnittstellen nutzen.

Serviceorientierte Architekturen ermöglichen ein hohes Maß an Flexibilität in der Entwicklung, denn kleine, bedarfsorientierte Services lassen sich jederzeit leicht ergänzen oder ersetzen, wenn neue Anforderungen aufkommen.

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Lesetipp: Einen Überblick und Starthilfe für die Arbeit mit Microservices bietet das E-Book von Eberhard Wolf, dass man hier kostenlos herunterladen kann.

Monolith versus Serviceorientierter Architektur

MONOLITHISCHE ARCHITEKTUR SERVICE-ARCHITEKTUR
Anwendung eine einzige, integrierte Software-Instanz in modulare Komponenten zerlegt
Umgebung einzelner Server oder VM kann über Clouds und eigenes Rechenzentrum verteilt werden
Erweiterungen erfordern Redeployment der gesamten Anwendung erfordern nur die Aktualisierung der einzelnen Services
Hauptvorteil Einfache Installation und Deployment Entwicklung neuer Funktionen einfach und flexibel
Hauptnachteil Skalierbarkeit der Funktionen begrenzt Orchestrierung der Funktionen und Wartung aufwändig
Geeignet für Kleine und mittlere Shops überschaubarer Innovationsrate Ambitionierte E-Commerce-Plattformen, mit raschen Innovationszyklen und Wachstumsplänen

Es gibt keine allgemeingültige Liste der Vor- und Nachteile von Monolithen und Microservices, beide sind mit bestimmten Kompromissen verbunden. Deshalb analysieren wir bei eCube bei jedem Projekt sehr sorgfältig die Anforderungen, um im konkreten Fall die optimale Lösung für unsere Kunden finden zu können.

Monolithische Architektur versus Service-Architektur (Quelle: Commercetools)

Abbildung: Monolithische Architektur versus Service-Architektur (Quelle: Commercetools)

Monolithische Systeme schrittweise entflechten

In vielen unserer Projekte geht es darum, monolithische E‑Commerce-Systeme, die im Laufe der Jahre sehr komplex und dabei gleichzeitig zu unflexibel für eine wirtschaftliche Weiterentwicklung geworden sind, zu entflechten.

Statt das gesamte System von Grund auf neu zu bauen (was in den meisten Fällen mit einem nicht verantwortbaren Risiko verbunden wäre), lösen wir schrittweise einzelne Funktionen aus dem Monolithen heraus. Diese werden dann durch Services ersetzen, die diese Funktionen übernehmen. Dabei folgen wir dem Prinzip der “Strangler Pattern”.

Prinzip der Strangler Pattern im E‑Commerce

Prinzip der Strangler Pattern im E‑Commerce

In diesem Beispiel wird im ersten Schritt das Preismanagement aus dem System in einen Service ausgelagert. Danach folgen schrittweise die übrigen Funktionen, sodass am Ende ein Netzwerk von Services steht, die miteinander kommunizieren. Wir nennen dies “Service Mashup”. In diesem Prozess bietet sich auch die Möglichkeit, einzelne Funktionen zu erneuern oder durch Standard-Services z.B. für die Produktsuche zu ersetzen.

Während beim monolithischen System in der Regel verschiedene Teams damit beschäftigt sind, mehr oder weniger trennscharf an “ihren” System-Bereichen zu arbeiten, können im Service Mashup die Zuständigkeiten entsprechend der Organisationsstruktur definiert werden. Im Idealfall wird jeder Service von einem dedizierten Team betreut. So ergibt sich die Möglichkeit, Systemstrukturen mit Organisations- oder Teamstrukturen gemäß Conways Law in Einklang zu bringen.

„Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“
Melvin E. Conway

Tipps für die Entwicklung serviceorientierter Architekturen

Der Umfang jedes einzelnen Services ist begrenzt. Das macht die Entwicklung, Wartung und Aktualisierung der Dienste einfacher als in monolithischen Systemen.

Andererseits wächst mit jedem neuen Service die Komplexität des Gesamtsystems. Bei eCube wägen wir deshalb in jedem Projekt genau ab, ob und an welchen Stellen eine Zerlegung nach Aufgaben bzw. Funktionen möglich, ohne dass der Aufwand den Nutzen übersteigt.

Damit auch kleinere aber ambitionierte Online-Shops ohne großes Entwicklungsteam von einer Service-Architektur profitieren können, sollte man bei der Planung und Entwicklung folgende Aspekte zu berücksichtigen:

Infrastruktur auslagern

Systeme wie beispielsweise Kubernetes für die Bereitstellung, Skalierung und Verwaltung von Services sollten so weit wie möglich ausgelagert werden, um die Komplexität der eigenen System-Landschaft nicht unnötig zu erhöhen. In Frage kommen hier Platform-as-a-Service-Angebote, die neben der Server-Infrastruktur auch das Betriebssystem beinhalten. Diese Komplettpakete sind zwar teurer, als das Hosting auf eigenen Servern, aber in der Gesamtbetrachtung eines Projektes oft kostengünstiger.

Fertige Services nutzen

Nicht alle Services müssen individuell entwickelt werden, vielmehr empfiehlt es sich, möglichst viele fertige Services wie z.B. den eCommerce-Service von commercetools, die Produktsuche von Factfinder und andere zu nutzen. Fertige Services lassen sich einfacher und zuverlässiger Updaten, da die Service-Anbieter ihre Schnittstellen und Funktionen in der Regel fortlaufend pflegen.

Lesetipp dazu:

 

Fazit: Händler sollten rechtzeitig handeln

Händler werden häufig erst dann aktiv, wenn sie mit ihren E‑Commerce-Systemen bereits an Grenzen stoßen. Etwa wenn Funktionen nur bedingt mit vertretbarem Aufwand ergänzt oder erweitert werden können. Dann muss schnell gehandelt werden und es bleibt oft zu wenig Zeit, die Situation gründlich zu analysieren und Optionen abzuwägen. Es lohnt sich deshalb, regelmäßig die eigene Systemlandschaft auf den Prüfstand zu stellen, um mögliche Engpässe für die Weiterentwicklung frühzeitig zu erkennen und darauf adäquat reagieren zu können.

Wir unterstützen Sie dabei, Ihr digitales Business konsequent auf Wachstum und Skalierbarkeit auszurichten. Dafür entwickeln wir für Sie digitale Ökosysteme auf Basis agiler Methoden und smarter Technologien. Hier geht es zu unseren Leistungen

Artikel teilen

Auch interessant

Eine schwarze Leiterplatte, auf der rote und gelbe Elemente zu sehen sind. Die roten und gelben Leiter zeigen das Icon eines Ohres und eines Warndreiecks.
Barrierefreiheit im E-Commerce: Was auf Hersteller und Händler zukommt

Barrierefreiheit ist im digitalen Verkauf kein Nice to have. Neben dem natürlichen Interesse von Unternehmen, bestmögliche Kauferlebnisse zu bieten, gibt es ab Juni 2025 rechtliche Vorgaben.

Whitepaper: Digital Commerce Cookbook

Dieser Leitfaden soll Projektleiter, Commerce-Verantwortliche und IT-Entscheiderin Transformationsvorhaben in die Lage versetzen, das Replatforming eines monolithischen Systems hin zu einer flexibel orchestrierbare Software-Architektur mithilfe von agilen Methoden und Tools so zielgenau und gleichzeitig flexibel wie möglich zu steuern.