JAXenter: Otto ist seit über 66 Jahren im Geschäft, seit etwa 20 Jahren gibt es einen Online-Shop. Wie steinig war der Weg zum modernen Online-Handel?
Otto ist der einzig verbliebene große Katalogversender, der es ins digitale Zeitalter geschafft hat. Dafür musste sich Otto immer wieder neu erfinden und auch früh den Weg ins Internet wagen. Der Weg dahin war immer wieder steinig und es gab Höhen und Tiefen. Um dem wachsenden Wettbewerb und immer schneller umzusetzenden Anforderungen gerecht zu werden, musste sich Otto von Grund auf ändern. Dazu gehörte auch, otto.de von Grund auf neu zu entwickeln und auf innovative Methoden und Technologien zu setzen.
JAXenter: Ist es da nicht einfacher, die gesamte IT neu aufzuziehen und nur das Nötigste zu übernehmen und nur essentielle Dinge wie die Produktdatenbank auf modernere Lösungen zu migrieren?
Genau diesen Schritt haben haben wir bei der Neuentwicklung des Online-Shops im Jahr 2011 gemacht. Dieser Schritt ist nur möglich, wenn man die Produktentwicklung für einige Zeit aussetzt. Durch agile Methoden ist uns dieser Schritt gelungen.
JAXenter: Ihre Session dreht sich um Continuous Deployment auf einem historisch gewachsenen Konzern-Backend. Wieso ist es so schwierig, mit modernen Technologien auf altbewährten aufzusetzen?
Um dem wachsenden Wettbewerb und immer schneller umzusetzenden Anforderungen gerecht zu werden, musste sich Otto von Grund auf ändern.
Als wir unseren Shop komplett neu entworfen und gebaut haben, haben wir viel Wert darauf gelegt, dass unsere Software schnell beim Kunden ist. Mit diesem Schritt liegt, im Gegensatz zu vorher, sehr viel Verantwortung beim einzelnen Software-Entwicklungsteam. Dieses Team nimmt im Zuge von Continuous Deployment eine ganz neue Produktverantwortung wahr. Die Herausforderungen liegen dabei vor allem im Umgang mit Logging, Monitoring und Technologien wie Feature Toggles. Wenn man diese Herausforderungen meistert, ist der Umgang mit dem Altbewährten zu meistern.
JAXenter: Die neue Architektur nutzt Microservices – was waren die Gründe für die Entscheidung, auf Microservices zu setzen?
Wir haben die Architektur von otto.de von Grund auf neu entworfen und gebaut. Anstatt für einen Monolithen haben wir uns für eine vertikale, nach Fachlichkeit geschnittene Architektur entschieden. Diese Komponenten nennen wir Vertikalen. Im Laufe der Zeit merkten wir, dass selbst diese Vertikalen wieder zu groß wurden. Deswegen haben wir uns entschieden, kleinere Fachlichkeiten zu schneiden und Microservices zu verwenden.
Ein Microservice und damit eine Fachlichkeit wird leicht von einem Entwickler verstanden, kann leicht angepasst werden und neue Funktionalität kann so schnell zum Kunden gebracht werden. Die “Time-to-Market” ist ein sehr bedeutsamer Faktor für den Erfolg eines Online-Shops. Microservices sind eine Modularisierungstechnik und erzwingen durch technische Barrieren, dass die Architektur auch langfristig beibehalten wird.
Es gibt noch viele weitere Vorteile von Microservices, es ist aber auch wichtig, sich mit den Nachteilen zu beschäftigen und diese zu verstehen.
JAXenter: Wie genau sieht die Microservice-Architektur bei Otto nun technologisch aus?
Eine Microservices-Architektur ist nicht trivial aufzusetzen. Wir nutzen Technologien wie Apache Mesos, Marathon, Varnish und Docker. Eine detaillierte Beschreibung der von uns verwendeten Technologien und unserer Infrastruktur ist auf unserem Blog zu finden.
JAXenter: Im DevOps-Diskurs geht es einerseits um neue Technologie-Ansätze wie Microservices, Cloud, Container, Continuous Deployment. Andererseits gehen mit den technologischen Veränderungen organisatorische Veränderungen einher, um schlagfertige Teams zu ermöglichen. Manche sprechen in diesem Zusammenhang auch von einer DevOps-Kultur. Wie sahen diese kulturellen, organisatorischen Veränderungen in der IT von Otto aus?
Microservices haben viele Vorteile. Es ist aber auch wichtig, sich mit den Nachteilen zu beschäftigen.
Als wir mit unserer neuen Shop-Architektur begannen, entstanden unsere sogenannten Vertikalen. Jede Vertikale wird immer nur von einem Team betreut. Alle Skills, die benötigt werden, die Fachlichkeit einer Vertikale weiterzuentwickeln, sind in diesem Team vorhanden.
Das Thema “Operation” ist in diesem Zusammenhang ein sehr spannendes Thema. Am Anfang war auch ein Team-Mitglied aus dem Bereich Operations. Im Laufe der Zeit merkt man, dass das betriebliche Know-How von vielen Team-Mitgliedern genauso benötigt wird, wie andere Fähigkeiten. In diese Richtung (DevOps) wollen wir gehen, sind aber noch nicht ganz angekommen. Das Streben in diese Richtung ist ein spannender Prozess, denn man muss sich zum Beispiel auch mit Themen wie Bereitschaften, Backups oder Logging auseinander setzen.
