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 Software: Auch sie bestehen aus einzelnen Bausteinen, die sich ­beliebig miteinander kombinieren lassen. Damit unterscheiden sie sich von klassischer Shop Software, die als Komplett­lö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 Funk­tionalitä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 Funk­tionen wie etwa die Bestell­strecke 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-Sys­tem, wollten die volle Gestaltungsfreiheit und mehr Agilität", beschreibt Benedikt Stemmildt, Software Engineer bei Otto, die Motiva­tion 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.

Galeria Kaufhof schätzt hohes Entwicklungstempo

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.

30 Prozent Plus bei der Conversion

Bei Galeria Kaufhof wurde die Customer Journey in fünf große Vertikale ein­geteilt, vom Betreten des Shops über die Suche, die Produktdarstellung und die ­Bestellung bis zur abschließenden Kauf­betreuung. 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 Gesamt­architektur 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.

Hoher Grad an Automatisierung nötig

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.

Ausgefeiltes API-Management unverzichtbar

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.

Nur lohnenswert, wenn Vorteile überwiegen

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.

Offenheit für Veränderungen am Geschäftsmodell

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.

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.