Der Vorteil der Microservices Welt ist die Möglichkeit, das System in vielen Einzelteilen aufzubauen.
Im Interview mit dem freiberuflichen Münchener Software-Architekten Alexander Troppmann:
Microservices sind die Zukunft, wenn es um Online-Shopsysteme geht. Der modulare Aufbau macht das System flexibler und verkürzt die Entwicklungszeit bis zum Livegang. Gleichzeitig wird die Software in Zukunft besser wartbar. Erfahren Sie, wie eine moderne Softwarearchitektur Ihren Onlineshop revolutionieren kann.
Alex, du arbeitest seit über 25 Jahren als Softwareentwickler und Softwarearchitekt. Du bist Speaker auf Kongressen und hast erfolgreich einen Onlineshop geführt. Welche Entwicklungen siehst Du im Gebiet der Softwarearchitekturen im E-Commerce?
Manuel, erst mal vielen Dank für das Interview heute. Im Bereich eCommerce war es eigentlich schon immer so, dass man mit sehr vielen Third-Party-Systemen zu tun hatte. Kein Onlineshop besteht nur aus dem Onlineshop selbst, sondern im Hintergrund arbeiten viele andere IT-Systeme für das Produktmanagement, für das Content-Management, das Marketing, die Suchmaschinenoptimierung und selbstverständlich die Lagerhaltung inklusive Verfügbarkeiten und Preise.
Neulich habe ich die Expertise eines großen Business Analysten gelesen. Demnach bestehen die meisten E-Commerce-Systeme aus Integrationen von bis zu 40 verschiedenen IT-Systemen unterschiedlicher Anbieter. Mit anderen Worten, es besteht eine hohe Komplexität mit vielen beteiligten Softwareprodukten.
Ein Trend, den ich in den letzten Jahren beobachtet habe, geht in Richtung Composable Commerce. Das bedeutet, dass man die Basiskomponenten eines Online-Shops im Prinzip nicht mehr selbst baut, sondern dass der Online-Shop aus vielen vorgefertigten Komponenten zusammengesetzt wird. Und das betrifft nicht mehr nur die Komponenten im Hintergrund wie ERP [Enterprise Resource Planning] und PIM [Product Information Management], sondern auch die Systeme, die direkt mit dem Kunden zu tun haben. Also das Frontend, aber auch das Backend, also der Teil der Software, in dem die Daten gespeichert sind, die der Kunde im Online-Shop sieht.
Composable Commerce bedeutet also, dass ich den Onlineshop aus fertigen Standardkomponenten aufbaue, wie z.B. Shopping Cart, Landing Pages, Product Listing Pages, Product Detail Pages. Dafür gibt es fertige Komponenten, die mir im Prinzip die Persistenz und auch schon 80 Prozent meiner Business-Funktionalität zur Verfügung stellen. Darauf aufbauend kommen die unternehmensspezifischen Geschäftsprozesse hinzu, mit Hilfe eigener Softwareentwicklung. So kommt man in viel kürzerer Zeit als früher zu einem fertigen Onlineshopsystem. Das dennoch individuell angepasst werden kann.
Welche Probleme und Herausforderungen entstehen für Unternehmen im Zusammenspiel dieser verschiedenen Systeme und Komponenten?
Eines der Hauptprobleme, auf die ich immer wieder stoße, besteht darin, dass ein Unternehmen für verschiedene Produkttypen unterschiedliche Onlineshops betreibt. Häufig liegt dies daran, dass ein Unternehmen gewachsen ist. Im Laufe der Zeit bieten dann oft verschiedene Abteilungen Produkte über einen digitalen Kanal an, ohne jedoch von Synergien und gemeinsam genutzter Technik profitieren zu können. Natürlich besteht der Wunsch seitens des Kunden, sprich des Besuchers des Onlineshops, möglichst alle Produkte eines Unternehmens aus einer Hand zu bekommen. Das ist mit solch einer inhomogenen E-Commerce-Landscape leider meistens nicht möglich.
Wenn ich z. B. ein Stück Hardware kaufe und die Firma bietet dafür auch eine geeignete Software an, kann es passieren, dass ich mich als Kunde zweimal einloggen muss. Wenn ich Pech habe, muss ich mich sogar zweimal registrieren. Das Problem entsteht, weil die Daten in verschiedenen Backendsystemen gehalten werden. Damit das am Ende, im Sinne einer einheitlichen Customer Journey zusammenspielt, habe ich von der technischen Seite her, große Herausforderungen. Die Lösung setzt auf ein großes System im Vordergrund und viele kleine Systeme im Hintergrund, indem die Informationen verteilt sind. Auch Frontends können übrigens wieder verwendet werden, man redet dann entsprechend von sogenannten Micro Frontends.
Wie kann deiner Meinung nach, diese Komplexität reduziert werden und Prozesse flexibler bzw. schneller gestaltet werden?
Mein Ansatz ist seit einigen Jahren, verstärkt auf Microservices zu setzen. Die Grundidee von Microservices-Architekturen ist eine andere als noch vor zehn Jahren, als Software grundsätzlich als Monolith gebaut wurde. Ein Monolith ist praktisch, wie der Name schon sagt, ein großes Stück Software. Das im Übrigen auch Vorteile hat. Aber eben auch einige Nachteile. Und der größte Nachteil zeigt sich gerade dann, wenn ich einen kleinen Teil des Monolithen verändern möchte. Denn dann muss ich permanent den ganzen Monolithen pflegen, aktualisieren, testen und warten. Der Vorteil der Microservices Welt ist die Möglichkeit, das System in vielen Einzelteilen aufzubauen. Die kleineren Einzelteile können so viel leichter ausgetauscht werden. Zum Beispiel, um einen Zahlungsanbieter im Onlineshop zu wechseln.
In einer Composable-Commerce-Welt, die auf einer Microservices Architektur basiert, wäre das dann folgendermaßen: Beispielsweise wird das Payment in einen Service ausgelagert. Bei einer Modifikation, wird nur dieser eine Service angepasst. Vielleicht würde ich sogar neben diesem Zahlungsservice einen zweiten aufbauen. Auch das ist in einer Microservices Welt möglich. Sprich, ich bin viel schneller beim Ziel, dass ich neue Zahlungsanbieter integrieren kann, ohne dass ich die bestehenden Zahlungsanbieter über Bord werfen muss. Mit anderen Worten, ich kann Migrationen durchführen, was ein großes Problem in der Softwareentwicklung löst. Später kann ich meinen neuen Microservice auch Schritt für Schritt in Live-Betrieb nehmen, indem ich zunächst 50% meiner Kunden online schalte. Erst wenn ich sicher bin, dass der neue Microservice so funktioniert, wie er soll, schalte ich irgendwann 100% der Kunden auf den neuen Programmteil um.
Meistens kennt man nur den Big Bang. Etwas wird jahrelang gebaut. Wenn es fertig wird, gibt es den Big Bang und alles geht auf einmal live. Man schaut einfach, was passiert, sozusagen. Wenn es nicht fertig wird, gibt es auch einen Big Bang. Dann hat die Entwicklung nämlich einen Haufen Geld verschlungen, ohne Ergebnis.
In einer Microservice-Welt habe ich aber den Vorteil, dass ich keinen Big Bang brauche, sondern einen Teil der Software weiterentwickeln und auch step by step immer wieder releasen kann. So kann ich meinen Kunden schon die ersten neuen Funktionen zur Verfügung stellen. Und dann die Software weiter optimieren.
Für welche Unternehmen ist es sinnvoll, eine servicebasierte Architektur mit Hilfe von Microservices zu implementieren?
Ja, das ist eine sehr gute Frage. Als Entwickler würde ich sagen, dass es für jedes Unternehmen sinnvoll ist. Aber als Softwarearchitekt sehe ich natürlich das Gesamtbild. Eine Microservices Architektur erfolgreich zu implementieren, hat einen sehr hohen Anspruch an die Entwickler. Das ist eine andere Vorgehensweise, als man sie noch vor vielleicht fünf oder zehn Jahren in der Softwareentwicklung hatte.
Es werden Experten mit hohen Skills benötigt, die ein anderes Mindset mitbringen.
Mit anderen Worten, das ist tatsächlich eher etwas für Unternehmen mit einer gewissen Größe, die etwas mehr Budget zur Verfügung haben. Ich spreche hier von großen mittelständischen Unternehmen, bis hin zu Konzernen. Soll aber nicht heißen, dass ein kleines Unternehmen mit Microservices gar nichts machen kann oder sollte. Insbesondere Composable Commerce kann mit seinen Bausteinen bereits sehr viel bewirken und bei der Entwicklung helfen.
Es gibt typische Komponenten im E-Commerce, wie zum Beispiel das E-Mail-Marketing. In einem klassischen Online-Shopsystem gibt es die sogenannten transaktionalen Mails, etwa bei Bestellabschluss. Eine Auftragsbestätigung oder Rechnung. In einer Microservices-Welt würde man jetzt einen Notification-Service implementieren, der das ganze Thema dieser Interaktion, zwischen meiner Technik und dem Kunden in einem digitalen Kanal abbildet.
Ich habe es jetzt bewusst allgemein formuliert, denn wenn man an die Zukunft denkt, dann gehören ja auch Themen wie die Messenger Dienste mit dazu, zum Beispiel. Das wäre auch eine Form von Notifizierung, die der Kunde dann auf sein Smartphone bekommt. Oder vielleicht in einen Chat Room eines Social Networks. Oder auf seine Alexa die zu Hause steht.
All das kann auch ein kleines Unternehmen mit der Auslagerung dieser Dienste in Microservices besser handhaben. So werden Aktivitäten auf die entsprechenden Service umgelenkt. Durch die zentrale Stelle im Management, ist es dann natürlich leichter, neue Features reinzubringen und zu entwickeln. Im Übrigen muss man das nicht selbst bauen. Man kann vieles als fertige Komponente einkaufen.
Man muss nicht alles selbst bauen. Das ist die Idee der Microservices-Welt.
Auch die Integration in die eigene IT, als Software as a Service oder Platform as a Service, ist denkbar. Natürlich spielt auch hier die Cloud eine immer größere Rolle. In der Cloud habe ich Zugriff auf nahezu unbegrenzte Ressourcen und das sehr schnell. Als Architekten sprechen wir hier oft von Elastizität, Skalierbarkeit und Resilienz. Alles Themen, für die Microservices eine Lösung sein können.
Der Ansatz gerade für kleinere Unternehmen und Online-Shops wäre also, Teilbereiche herauszulösen und in eine serviceorientierte Architektur zu überführen?
Exakt. Das ist tatsächlich unabhängig von der Größe des Unternehmens möglich. Ich würde sagen, je größer das Unternehmen, desto mehr Teile kann man extrahieren. Je kleiner das Unternehmen, desto weniger Teile sollte man extrahieren, weil es einfach auch eine Kostenfrage ist. So eine Softwaremigration kostet unglaublich viel Geld und erfordert ja auch eine ordentliche Portion an Wissen. Auch aus organisatorischer Sicht.
Worauf ist beim Umstieg auf Microservices zu achten?
Man muss dazu sagen, wenn Konzerne heutzutage auf Microservices Architekturen umstellen, reicht es nicht, nur die technische Vorgehensweise zu ändert. Es muss sich auch die organisatorische Vorgehensweise anpassen. Wir sprechen dann von agilen Methoden, die man einführt. Das Management von mehreren Scrum Teams, also Scrum of Scrum, ist eine Richtung, an die ich denke. Als kleines Unternehmen bin ich aber trotzdem in der Lage, genau auf die gleiche Art Migration zu machen, indem ich mir beispielweisen mal nur die Art und Weise ansehe, wie ich mit meinen Emails arbeite und die Frage stelle, kann ich das verbessern.
So sucht man sich anfangs einen kleinen Teil aus der meist monolithischen Welt heraus. Und den baut man dann neu. Und das ist der erste Schritt zur Migration. Und genauso würde man vorgehen. Das heißt, je mehr Kapazitäten ich habe, sei es jetzt an Technikern oder auch an Budget, das mir zur Verfügung steht, werden nach und nach immer mehr Teile, wie Payment, E-Mail oder Marketing aus dem bestehenden eCommerce-System herausgelöst. Man spricht in der Softwarearchitektur hierbei auch vom Strangler Pattern.
Ist eine servicebasierte Architektur erst implementiert, wo kann die Reise dann hingehen? Welche Trends siehst du in diesem Bereich?
Ich glaube, der aktuelle Trend ist KI. Ich nenne das Social Commerce. Da wird zum Beispiel versucht, Verkäufe in Chatverläufe zu integrieren. Wenn man sich vorstellt, das noch mit künstlicher Intelligenz zu verknüpfen, also ich spreche mit einer KI und lasse mich für mein neues Auto oder meinen nächsten Urlaub beraten, dann könnte das auch in der E-Commerce-Plattform als Aktionen in einer API angeboten werden.
Die KI könnte dann aus dem Gespräch heraus sofort den Kaufvertrag abschließen. Ich glaube, das ist tatsächlich die Zukunft. Weg vom klassischen Onlineshop, hin zum digitalen Einkaufserlebnis auf allen möglichen und denkbaren Kanälen.
Denn letztlich ist der Käufer in einem Onlineshop sehr stark vom Augenblick getriggert.
Und wenn ich gerade im Gespräch bin und die KI sagt zu mir: Hey, ich habe schon alles vorbereitet für dich, hier kannst du unterschreiben. Ich glaube, das ist einfacher für den Kunden.
In Zukunft wird man sich weniger durch einen Onlineshop klicken, sondern eher spontan und impulsiv einkaufen.
Ich denke, da geht die Reise hin. In Zukunft wird man sich weniger durch einen Onlineshop klicken, sondern eher spontan und impulsiv einkaufen. Und ich glaube, dass es mit einer servicebasierten Architektur, wie ich sie heute beschrieben habe, viel einfacher sein wird, auf diese Veränderungen zu reagieren. Denn Microservices können als Bausteine für eine Vielzahl von User Journeys eine wiederverwendbare Basis für Daten und Funktionen bieten.
Alex, vielen Dank für die aktuellen Einblicke in die Welt der Softwarearchitektur im E-Commerce.