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.
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, sodass 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.
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 E-Commerce-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.
Eine kurze Einführung in das Konzept der Microservices gibt Kelly Goetsch, CPO von commercetools im folgenden Video:
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 Service Mashup
| 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.
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 und ersetzen sie durch Services, die diese Funktionen übernehmen. Dabei folgen wir dem Prinzip der “Strangler Pattern”.
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
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 E-Commerce-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.
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 haben hierfür einen speziellen Analyse-Workshop entwickelt, in dem Online-Händler mit unserer Unterstützung ermitteln können, ob und wann sich beispielsweise eine Umstellung von monolithischem Shop-System auf eine Serviceorientierte Architektur anbietet.
Fotolia
