Retail IT


Cloud-Migration bei eDreams ODIGEO

Microservices ersetzen Monolithen

Jens Dose ist Editor in Chief von CIO. Seine Kernthemen drehen sich rund um CIOs, ihre IT-Strategien und Digitalisierungsprojekte.
CIO Carsten Bernhard migrierte die gesamte IT des Online-Händlers auf eine Microservices-basierte Cloud-Plattform. Das reduziert die IT-Kosten und beschleunigt die Produktentwicklung.
Carsten Bernhard ist CIO von eDreams ODIGEO.
Carsten Bernhard ist CIO von eDreams ODIGEO.
Foto: eDreams ODIGEO

"Wir liefern keine Software oder Produkte, wir liefern Geschäftserfolg," erklärt Carsten Bernhard das Selbstverständnis der IT-Abteilung von eDreams ODIGEO. Mit dem Projekt "Cloud Agility at Scale" stellte er die IT technisch und organisatorisch so auf, dass sie dieser Aufgabe auch in einem stark umkämpften Markt gewachsen ist. Innerhalb von zwei Jahren migrierte er die zentrale technische Plattform des Unternehmens auf eine Microservices-basierte Cloud-Plattform. Zudem organisierte er einen Großteil der rund 400 IT-Mitarbeiter in agilen Teams.

Geschwindigkeit ist Trumpf

eDreams ODIGEO ist ein Online-HändlerOnline-Händler von Flugtickets und besitzt Marken wie Opodo, GO Voyages, Travellink und Liligo. "In dieser Branche ist es sehr wichtig, schnell auf Kundenwünsche eingehen zu können und bessere Services als die Konkurrenz zu bieten," so der CIO. Die gesamte Wertschöpfung des Unternehmens laufe über die IT-Systeme. Daher sei der Anteil an Standard-Software sehr gering und beschränke sich auf Systeme, die nicht wettbewerbsdifferenzierend sind, etwa die Buchhaltung. Bernhard: "Wir sind eigentlich ein Softwareunternehmen. 97 Prozent unserer IT-Kollegen arbeiten in der Entwicklung und dem Betrieb der eigenen Plattform." Top-Firmen der Branche Handel

Mit der alten On-premises-Infrastruktur wurde es zunehmend schwierig, Software so schnell und skalierbar zu entwickeln, wie der Markt es verlangte. ServerServer für Neuentwicklungen anzuschaffen und einzurichten war teuer, das Verhältnis von Kosten zum Wertbeitrag nicht transparent. Musste im laufenden Betrieb der Server für eine Anwendung neu gestartet werden, dauerte es bis zu fünf Minuten, bis der Dienst wieder erreichbar war. Auch deshalb entschied sich Bernhard für eine Cloud-Umgebung. Alles zu Server auf CIO.de

Enge Zusammenarbeit mit dem Provider

Der CIO setzt dafür auf die GoogleGoogle Cloud. "Zum einen passt die DNA von Google und eDreams ODIGEO gut zusammen, beide sind stark entwicklungsorientiert mit großem Fokus auf AI." Zum anderen habe sich der Cloud-Anbieter bemüht, eng mit dem Team um Bernhard zusammenzuarbeiten. "Wir sind beispielsweise direkt mit den Entwicklern von Kubernetes in Kontakt, um gemeinsam spezielle Container-Lösungen für uns zu erstellen." Alles zu Google auf CIO.de

Auch bei der Datenbank-Migration zogen Kunde und Provider an einem Strang. eDreams ODIGEO nutzt eine Oracle-Datenbank für einige Backend-Prozesse, die in der Regel schwierig in die Google-Landschaft einzubinden ist. Die Lösung: Man verschob die Datenbank in die Oracle-Cloud und in räumlicher Nähe zu dem Google-Rechenzentrum, in dem auch die Server des Unternehmens stehen. Dort sind beide physisch über ein Netzwerk-Gateway verbunden, so dass die Datenbank in die Cloud-Infrastruktur eingebunden ist. "Google hat sich aktiv darum bemüht, diese Lösung gemeinsam mit uns zu finden," so Bernhard. "Das zeigte uns, dass wir nicht nur irgendein weiterer Kunde sind."

Teilen und herrschen

Die großen monolithischen Programmteile der alten Infrastruktur zerlegte das Team um Bernhard in Microservices, die in Containern vorgehalten werden. Aktuell betreibt die eDreams-IT rund 150 Container auf Basis der Open-Source-Plattform Kubernetes. Jeder Microservice läuft selbstständig. Die Softwaremodule können deshalb unabhängig voneinander entwickelt, getestet und betrieben werden. Fällt ein Service aus, läuft das restliche System weiter.

"Jeder Microservice hat zudem perspektivisch seine eigene Datenhaltung," so der CIO, "Wenn wir wirklich jedes Modul unabhängig entwickeln wollen, müssen auch die Daten unabhängig sein." Bei einer zentralen Datenbank müssten sich die Entwickler jedes Mal abstimmen, wenn sie etwas ändern wollen, wodurch viel Geschwindigkeit verloren gehen würde. Für den Austausch transaktionaler Daten, etwa für einen Bezahlprozess, kommunizieren die Module direkt miteinander, damit die Daten stets konsistent bleiben.

Zur Startseite