INTERNET WORLD Business





Shops aus Bausteinen

Online-Shops werden immer komplexer. Oft kommt die bestehende Software-Architektur da nicht mehr mit. Modulare Systeme sind gefragt, etwa auf Basis von Microservices

Was begeistert Kinder an Legosteinen? Es ist wohl die große gestalterische Freiheit: Die kleinen Ingenieure können damit alles bauen, was ihnen in den Sinn kommt. Die Teile passen immer zusammen und das Gebaute lässt sich schnell verändern und erweitern.

Ähnlich verhält es sich mit modular aufgebauten Shop-Systemen: Auch sie bestehen aus einzelnen Bausteinen, die sich beliebig miteinander kombinieren lassen. Damit unterscheiden sie sich von klassischer Shop-Software, die als Komplettlösung alle für den Shop-Betrieb nötigen Standardelemente enthält. Solche sogenannten monolithischen Systeme stoßen jedoch immer häufiger an ihre Grenzen, weil sich die einzelnen Elemente nicht rasch oder umfassend genug ausbauen lassen – vor allem, wenn in einem sehr dynamischen Marktumfeld schnell neue Funktionen angebunden werden müssen.

Offene Architektur mit Microservices

Eine Möglichkeit, solch starre Strukturen aufzubrechen, ist eine offene Shop-Software-Architektur auf Basis von Microservices. Unter einem Microservice versteht man ein kleines, eigenständiges und in sich abgeschlossenes Stück Software, das eine klar umgrenzte Funktionalität abdeckt. Für eine Microservice-Architektur wird nun die Shop-Software vertikal in ihre funktionalen Bestandteile zerlegt. Das können Bausteine wie die Shop-Suche, die Produktpräsentation oder die Bestellstrecke sein. Diese Trennung in einzelne Bestandteile wird auch als Aufteilung in Vertikale oder Domänen oder als fachlicher Schnitt bezeichnet.

Für jede Fachlichkeit wird ein oder mehrere eigenständige Microsoervices programmier und mit Schnittstellen ausgestattet. Über diese Schnittstellen werden alle Microservices miteinander verbunden, sodass sie als Ganzes sämtliche Shop-Funktionalitäten bereitstellen. Für jeden Microservice ist ein autonom agierendes Team zuständig, das sowohl die Entwicklung als auch den Betrieb dieser Funktion verantwortet.

Unabhängigkeit schafft große Flexibilität

Der große Vorteil: Microservices können schnell und unabhängig voneinander entwickelt, eingesetzt und verändert werden. Dadurch entsteht eine große Flexibilität, weil eine Veränderung an einem Microservice keinerlei Auswirkungen auf das Gesamtsystem hat. So kann beispielsweise eine optimierte Version der Shop-Suche sofort in den laufenden Betrieb übernommen werden, da keine Gefahr besteht, dass sie andere Funktionen wie etwa die Bestellstrecke oder die Produktpräsentation beeinträchtigt.

Vorreiter für solche Microservice-Architekturen waren in den USA Unternehmen wie IBM, Amazon oder der Streaming-Dienst Netflix. In Deutschland haben große Händler wie Zalando, Otto und Galeria Kaufhof die Vorteile für sich entdeckt.

So ist Otto.de Ende 2013 mit einem neuen Shop online gegangen, der mittlerweile an vielen Stellen über selbst entwickelte Microservices läuft. „Wir wollten unabhängig sein von einem Standard-Shop-System, wollten die volle Gestaltungsfreiheit und mehr Agilität“, beschreibt Benedikt Stemmildt, Software Engineer bei Otto, die Motivation für den Umstieg. Heute kümmern sich knapp 20 Teams aus jeweils zehn bis 15 Mitarbeitern um verschiedene Fachlichkeiten wie Produkt, Suche, Kundendaten, Personalisierung, Service oder Bestellstrecke.

Microservices bieten große Skalierbarkeit

Ein Beispiel: Zu der Fachlichkeit Bestellstrecke gehören Bausteine wie der Warenkorb, die Adresseingabe oder auch der Merkzettel. „Es hat sich schnell gezeigt, dass der Merkzettel ein idealer Anwendungsfall für einen Mircoservice ist: zum einen wegen seiner klar umrissenen Funktionalität, zum anderen, weil wir uns gut vorstellen können, dass wir diesen Service in den kommenden Jahren stark ausbauen werden, etwa in Richtung Social Media“, erklärt Martin Kalsow, Technical Designer bei Otto.

Für Stemmildt und Kalsow liegen die Vorteile in der Skalierbarkeit, aber auch in der Ausfallsicherheit: Fällt ein Baustein aus, bleiben alle anderen Funktionalitäten des Shops trotzdem in Betrieb.

Das liegt vor allem an der kompletten Unabhängigkeit der einzelnen Microservices. „In einem Shop benötigen ganz verschiedene Funktionen Produktdaten: die Produktdetailseite, die Suche, der Warenkorb, der Merkzettel usw. Bei einem monolithischen System liefert eine große Datenbank diese Daten, alle Services greifen auf diese eine Datenbank zu. Bei einer Microservice-Architektur enthält jeder Microservice seine eigene Datenbank. Deswegen sind die Services so unabhängig voneinander und können auch alle einzeln deployed, also in Betrieb genommen werden“, sagt Kalsow.

Die große Flexibilität, die hohe Entwicklungsgeschwindigkeit und die sofortige Einsetzbarkeit der einzelnen Bausteine waren auch für Galeria Kaufhof wichtige Argumente für den Umstieg auf Microservices. „Wir waren mit unserer vorherigen Plattform Hybris, die über Arvato als externen Dienstleister entwickelt wurde, nicht unzufrieden. Aber für uns war absehbar, dass sie für die von uns geplanten Dimensionen nicht mehr ausreichen würde“, erklärt Arik Reiter, Chief Digital/Product Officer bei Galeria Kaufhof.

Eineinhalb Jahre hat die Entwicklung des neuen Shops gedauert, der im Mai 2015 online gegangen ist. Rund 60 Entwickler und Berater waren beteiligt, zwei Drittel davon von externen Dienstleistern. Heute sind rund 80 Mitarbeiter mit der Produktentwicklung beschäftigt, davon zwei Drittel inhouse.

Bei Galeria Kaufhof wurde die Customer Journey in fünf große Vertikale eingeteilt, vom Betreten des Shops über die Suche, die Produktdarstellung und die Bestellung bis zur abschließenden Kaufbetreuung. Darunter liegen viele einzelne Microservices. So kann im Bestellprozess die Anbindung einzelner Payment-Verfahren über Microservices erfolgen. Das macht das System skalierbar, etwa für die anstehende Internationalisierung. Wenn die Plattform in Kürze in Belgien online geht, können die verschiedenen Payment-Verfahren nach Bedarf in die Gesamtarchitektur eingebunden werden.

Bislang ist Reiter sehr zufrieden mit dem Umstieg: Der Umsatz des Online-Shops von Galeria Kaufhof wächst doppelt so schnell wie der E-Commerce-Markt. Die Conversion hat binnen eines Jahres um 30 Prozent zugelegt. Der Betrieb läuft ausfallsicher und merklich effizienter.

Dennoch: Microservice-Architekturen stellen auch eine Herausforderung dar. Da jeder Service in sich abgeschlossen ist, entstehen viele Redundanzen, etwa weil jeder Service seine eigene Datenbank betreibt. „Beim Einsatz von Microservices muss man vieles hundertfach bauen. Deswegen ist ein sehr hoher Grad an Automatisierung erforderlich, um die nötigen Strukturen schnell und effizient schaffen zu können“, betont Stemmildt. So kommt es beispielsweise darauf an, die verschiedenen Datenbanken automatisiert einrichten und die Daten ebenso automatisiert pflegen zu können, weil sowohl die Programmierung als auch die Wartung viel zu aufwendig wird. Einen solch hohen Automatisierungsgrad erreichen aber noch nicht viele Händler.

Eine zweite Herausforderung liegt im reibungslosen Zusammenspiel der Microservices. Wenn hundert verschiedene Bausteine zusammenpassen müssen, ist ein ausgefeiltes API-Management, also die Vereinheitlichung, Verwaltung und Pflege der Schnittstellen, unumgänglich.

Außerdem erfordert eine solche Architektur ein entsprechendes Budget: „Natürlich war dies kein leichtes Unterfangen für das Team, sondern erforderte in der Vergangenheit – aber auch in Zukunft – Investitionen in Millionenhöhe“, so Reiter.

Deswegen sollte eine Microservice-Struktur nur zum Einsatz kommen, wenn die Vorteile wie Geschwindigkeit und Flexibilität überwiegen. Dies gilt insbesondere dann, wenn immer wieder schnell innovative, marktdifferenzierende Geschäftsfunktionen entwickelt werden müssen, um im Wettbewerb zu bestehen. Zudem sind sie nur sinnvoll, wenn die Shop-Anforderungen für ein monolithisches System zu komplex sind. Das ist bei vielen derzeitigen Shops heute aber nicht der Fall.

„Je weiter weg die Anwendungen von reinen Shop-Funktionen sind, desto eher kann eine Microservice-Architektur ihre Stärken ausspielen“, betont Alexander Hofmann von der E-Commerce-Beratung Howado, die die Shop-System-Vergleichsseite Ecomparo betreibt. Bei kleineren Shops haben Standardsysteme seiner Meinung nach noch die Nase vorn. Erst wenn Premiumdienste, besondere Kundenbindungselemente oder Erweiterungen des Geschäftsmodells, etwa Abo-Commerce, dazukommen, seien flexible Architekturen nötig.

Seiner Meinung nach versuchen zudem viele Shop-System-Hersteller eine entwicklerfreundliche Umgebung zu schaffen, indem sie offene Schnittstellen sowie eine Vielzahl von Plug-ins anbieten. Dadurch würden auch sie eine schnellere Anpassung an Markterfordernisse ermöglichen. „Allerdings findet manchmal auch nur ein reines Rebranding statt, sodass sich hinter der vermeintlichen ‚Platform as a Service‘ doch eher ein klassisches Shop-System verbirgt“, sagt Hofmann.

Offenheit für Veränderungen am Geschäftsmodell

Ein wichtiges Unterscheidungsmerkmal für ihn ist, inwieweit das System für ein bestimmtes Geschäftsmodell definiert ist.

Laut Hofmann empfiehlt sich ein schrittweiser Umstieg: Statt eine Microservice-Architektur „auf der grünen Wiese“ aufzubauen, könne ein monolithisches System nach und nach über Microservices erweitert und zuletzt ganz abgelöst werden. ❚


Schrittweiser Umstieg ist ein wesentlicher Vorteil

Eberhard Wolff arbeitet als Fellow bei dem Software-Berater und -Entwickler Innoq in Berlin. Eines seiner Spezialgebiete sind Microservices. www.microservices-buch.de

Ein bestehendes monolithisches Shop-System lässt sich schrittweise durch ein Microservice-basiertes System ergänzen und ablösen.

Welche Faktoren können dafür sprechen, auf eine Microservice-basierte Architektur umzusteigen?

Eberhard Wolff: Eine häufige Motivation ist, dass Teams sich zu eng bei der Entwicklung der Software abstimmen müssen. Microservices führen zu einer stärkeren Entkopplung. Dadurch erlauben sie den Teams, weitgehend unabhängig voneinander an einzelnen Microservices zu arbeiten. Außerdem bieten sie technische Vorteile wie getrennte Skalierbarkeit oder ein wesentlich einfacheres Deployment.

Wie kann ein bestehendes monolithisches Shop-System abgelöst werden?

Wolff: Microservices können ein bestehendes System ergänzen. Dadurch kann eine Migration schrittweise erfolgen, indem immer mehr Funktionalitäten von Microservices übernommen werden. Diese Möglichkeit ist ein wesentlicher Vorteil der Microservices-Architektur. Eine Migration weg von einem bestehenden System ist der übliche Anwendungsfall von Microservices.

Was ist die größte Herausforderung bei einem Umstieg?

Wolff: Der fachliche Schnitt wird wichtiger, weil nur durch eine gute Aufteilung die notwendige Entkopplung erreicht werden kann. Außerdem steigt die Anzahl der deploybaren Funktionen. Das bedingt die Automatisierung von Betriebsprozessen. Das ist beides nicht unbedingt schlecht: Ein besserer Schnitt und eine bessere Automatisierung sind sowieso wünschenswert und führen zu erheblichen Optimierungen.


Glossar

Microservices

Unter Microservices versteht man eigenständige, in sich abgeschlossene kleine Software-Bausteine, die eine klar begrenzte Funktionalität abdecken. Da sie oft nur aus wenigen Hundert Zeilen Code bestehen, lassen sie sich schnell entwickeln und skalieren. Für einen Microservice ist ein autonom agierendes Team zuständig, das ihn entwickelt und betreibt.

Fachlichkeit / Vertikale / Domäne

Für eine Microservice-basierte Software-Architektur wird ein Software-System vertikal in sinnvolle Funktionseinheiten aufgeteilt. Die Termini für die Aufteilung sind: Vertikale, Domäne oder Fachlichkeit. Hin und wieder wird auch vom fachlichen Schnitt gesprochen.

Continuous Deployment

Da Microservices in sich abgeschlossen, unabhängig und eigenständig funktionsfähig sind, können sie unmittelbar nach der Fertigstellung eingesetzt werden. Im Gegensatz zu einigen wenigen Software-Releases pro Jahr werden Neuerungen fortlaufend in Betrieb genommen. Dies nennt man Continuous Deployment.

Weitere Bilder
comments powered by Disqus