Tech perspective of an eFood Marketplace from REWE

Der Aufstieg eines eFood Marktplatzes: Die Technologie Perspektive – 3 Fragen an Thomas Vidic, System Architekt REWE digital

commercetools author image Stephanie Wittmann
Stephanie Wittmann
Head of Communications & Content, commercetools
Published 04 February 2020

„Entwicklung lebt davon zu wissen, was in der Vergangenheit gelaufen ist.“

Fünf Jahre ist es her, dass REWE digital sich für die Microservices-Plattform commercetools entschieden hat – eine fruchtbare Zusammenarbeit für beide Seiten. In unserer Reihe zu diesem jungen Jubiläum haben wir bisher die Marketing- und E-Commerce-Profis der REWE digital zu Wort kommen lassen. Im dritten und letzten Teil sprachen wir mit Thomas Vidic, System Architekt bei REWE digital.

Im Tech-Team bei REWE digital arbeiten drei Squad Architekten. Aus dem commercetools-Baukasten nutzen sie in erster Linie das Merchant Center, um Daten und Prozesse zu verwalten, inklusive Product Information Management (PIM). REWE digital verfolgt den Ansatz, dass alle Mitarbeiter*Innen aus dem Bereich E-Commerce in einem monatlichen Meeting Ideen einbringen. Diese unterzieht Thomas Vidic einer Aufwandsbewertung. Im Zuge eines groben Business Cases werden die Vorschläge priorisiert und gefiltert, am Ende des Prozesses entscheidet die Geschäftsführung dann über das Portfolio. So generiert REWE digital sechsmal mehr Ideen, als letztlich umgesetzt werden.

Tech perspective of an eFood Marketplace from REWE

Warum habt ihr euch bei der Entwicklung des Marktplatzes und des Shops für eine Microservice-Architektur entschieden? Welche Vorteile seht ihr darin? Welche Herausforderungen habt ihr dabei zu meistern?

Als wir uns Ende 2014/ Anfang 2015 entschieden haben, welche Technologien wir künftig nutzen wollen, wurden Microservices in der Tech-Community sehr intensiv diskutiert. Uns hat in erster Linie die organische Skalierung für Microservices eingenommen, da uns von Anfang an klar war, dass die Plattform eine signifikante Größe erreichen muss, um den Business-Zielen gerecht zu werden. Das ist allerdings nur möglich, wenn Aufgaben parallelisiert werden können, also ein Team an einer gestellten Aufgabenlösung arbeiten kann, ohne dass Abhängigkeiten mit anderen Teams bestehen. Wenn man nicht dutzende Entwickler an einer einzigen monolithischen Software arbeiten lassen möchte, liegt die Entscheidung für Microservices auf der Hand.

Ein weiterer Beweggrund, war, dass der Funktionsumfang zu Beginn schwer einzugrenzen war. Da war es einfacher, das, was wir schon kannten, als kleinen Service einzubauen und nach und nach um andere Services zu ergänzen – statt in dieser Situation die Programmierung einer großen, vollumfänglichen Software zu planen. Gerade zu Beginn hatten wir fast nur Senior-Entwickler, die ausreichend Erfahrung mitbrachten, eine komplexe Microservices-Architektur zu konzipieren und umzusetzen. Übrigens haben wir mit zwei Teams begonnen und haben inzwischen mehrere Teams für Fullfillment und zusätzlich spezialisierte Content-Teams. Hinzu kommt noch eine große Anzahl von E-Com-Teams, die heute vielfältig und engagiert mit dabei sind. Ein deutlich gewachsenes Netzwerk an Kolleginnen und Kollegen, das uns technologisch und inhaltlich weiterbringt.

Nach welchen Prinzipien bestimmt ihr den Funktionsumfang der einzelnen Microservices? Wie sind die Microservices mit der Business-Logik verbunden?

Bei uns haben einzelne Teams die volle Verantwortung für „ihre“ Services – von der Konzeption über die Umsetzung bis hin zum täglichen Gebrauch, in dem sie sie betreiben. Dabei arbeiten wir nach dem Domain-Driven-Design-Prinzip: Die Teams sind nach Business-Domains, also Teilbereichen wie Product Discovery (darunter fallen z. B. Produktdetailseiten) oder Checkout (z. B. Warenkorb) organisiert. Nur in Ausnahmefällen arbeiten Teams oder einzelne Entwickler an wechselnden Themenfeldern. Allerdings gibt es Überschneidungen: So nutzen die Teams für den Warenkorb und die für die Suche beide die Produktdaten, müssen sich also dementsprechend organisieren. 

Auf welche weiteren Technologien setzt ihr? Wie stellt ihr sicher, dass auch neue technologische Ansätze verfolgt werden, die Architektur dabei aber effektiv bleibt?

Hauptsächlich nutzen wir Java, Scala, node.js und Kotlin. Jeder der drei Bereiche E-Commerce, Fullfillment und Content hat eine Liste an Programmiersprachen, die eingesetzt werden können. Dabei arbeitet jedes Team mit der Programmiersprache, mit der sich die geplanten Aufgaben am besten umsetzen lassen – allerdings in Absprache mit den Architekten.

Entscheidend bei der Auswahl sind nicht immer nur Effizienzgewinne. Wir beobachten, dass sich auch Teams rund um eine Technologie gruppieren und über die gemeinsame Nutzung stabil zusammenarbeiten. Aber: Nicht jede Programmiersprache, die gerade „hip“ ist, kommt bei uns zum Einsatz. Das würde im Endeffekt zu einem Wildwuchs von Technologien führen, und dadurch bekämen wir Probleme bei der Dokumentation und später bei der Gewinnung neuer Mitarbeiter. Schlussendlich ist es ein Balanceakt: Selbstverständlich möchten wir gute Entwickler mit neuen Technologien locken, dürfen dabei aber natürlich nicht die Kontrolle über den „Software-Zoo“ verlieren.

In den vorangegangenen Artikeln dieser Interviewserie haben wir uns die Marktplatz- und die E-Commerce-Strategie von REWE digital und ihr Zusammenspiel mit der commercetools-Plattform näher angesehen.

Mehr über REWE digital als Wegbereiter für die Digitalisierung der REWE Group finden Sie auf deren Website.

commercetools author image Stephanie Wittmann
Stephanie Wittmann
Head of Communications & Content, commercetools

Related Blog Posts