Projekte


Cloud-Migration in drei Monaten

Aroundhome wechselt in die AWS-Cloud

Jens Dose ist Redakteur des CIO Magazins. Neben den Kernthemen rund um CIOs und ihre Projekte beschäftigt er sich auch mit der Rolle des CISO und dessen Aufgabengebiet.
Der Berliner Plattformbetreiber Aroundhome migrierte seine gesamte Infrastruktur bei laufendem Betrieb in die AWS-Cloud. CTO und CIO Steffen Heilmann erklärt, wie das Projekt in nur drei Monaten gelang.

Unter dem Namen "Wolkenbruch" startete Steffen HeilmannSteffen Heilmann Anfang August 2019 die Migration von Aroundhome in die AWS-Cloud (AmazonAmazon Web Services). Das Berliner Unternehmen mit rund 500 Mitarbeitern betreibt eine Online-Plattform, die Handwerks- und Fachbetriebe an Eigenheimbesitzer vermittelt. Das Portfolio umfasst etwa 16.000 Betriebe und mehr als 50 Produkte; pro Woche müssen bis zu 40.000 Anfragen über die Vermittlungs-App bearbeitet werden. Profil von Steffen Heilmann im CIO-Netzwerk Alles zu Amazon auf CIO.de

Steffen Heilmann ist seit 2018 CTO und CIO bei Aroundhome in Berlin.
Steffen Heilmann ist seit 2018 CTO und CIO bei Aroundhome in Berlin.
Foto: Aroundhome

Pläne für den Wechsel zu einem CloudCloud-Hyperscaler existierten schon länger, allerdings war bereits ein Versuch, die zentrale Datenbank - das Herzstück des Unternehmens - in die Cloud umzuziehen, gescheitert. Seitdem wurde das Thema eher zurückhaltend behandelt. Anfang 2019 häuften sich jedoch die Probleme mit dem Rechenzentrum. Mehrstündige Betriebsausfalle aufgrund fehlerhafter Hardware und schlechter Service des Rechenzentrum-Dienstleisters veranlassten Heilmann, die Migration der kompletten Infrastruktur in die Cloud in Angriff zu nehmen. Das Vorhaben sollte innerhalb von drei Monaten abgeschlossen sein. Alles zu Cloud Computing auf CIO.de

Lift and Shift in 90 Tagen

Ziel war es, möglichst schnell aus dem Rechenzentrum zu gelangen. Daher entschied sich das Team um Heilmann für eine Lift-and-Shift-Migration der jeweils etwa 40 Anwendungen und Server, statt alles in der Cloud neu zu bauen. In Absprache mit dem Executive Board, in dem der CTO und CIO selbst sitzt, und der gesamten Firmen-IT wurde der Zeitraum von August bis Oktober für die Migration angesetzt.

"Drei Monate sind hinreichend lang, um komplexere Aufgaben wie eine Komplettmigration in die Cloud zu lösen; sie sind aber auch hinreichend kurz, um eine dedizierte Timeline aufrecht zu erhalten," erklärt Heilmann. Würde ein längerer Zeitraum, beispielsweise ein Jahr, für ein ähnliches Projekt angesetzt, passiere erfahrungsgemäß in den ersten drei Monaten sowieso nichts und das Team verliere den Fokus.

Im Vorfeld stockte Heilmann das IT-Betriebsteam durch Mitarbeiter auf, die über das nötige Know-how für die Migration in die AWS-Cloud verfügten. Dabei war es wichtig, nicht nur im Betriebsbereich Wissen aufzubauen, sondern auch in den Entwicklungsteams, da für den Wechsel unter Umständen Änderungen am Code notwendig würden.

Der "Buy-in" der Fachverantwortlichen für das Projekt gelang Heilmann, indem er ihnen die Vorteile der Cloud für das Business erklärte. Schnellere Entwicklung, Tests und Rollouts sowie bessere Skalierung und Performance der Webseiten führen zu höherwertigeren Produkten.

Für AWS als Provider sprach, dass es bereits einzelne Testumgebungen in der AWS-Cloud und damit Erfahrungen im Unternehmen gab. AWS sei den anderen Anbietern gefühlt ein halbes Jahr voraus was Entwicklungsthemen und Cloud-Services angehe, so Heilmann. "Außerdem ist AWS im Grunde Standard und die Skills für die Amazon-Plattform sind am Markt am einfachsten zu finden."

Automatisierter Dreisprung in die Cloud

Die Migration selbst baute Heilmann in drei Phasen auf. An erster Stelle stand die Planung anhand von drei Fragen: Wo stehen wir? Was wollen wir erreichen? Wie kommen wir da hin? Hier machte sich das Migrations-Team mit AWS vertraut, definierte Standards für die Bereitstellung in der Cloud, erfasste die vorhandenen Tools und solche, die noch angeschafft werden mussten.

Zudem galt es, ein Inventar aller zu migrierenden Apps und Server zu erstellen und diese anhand von gegenseitigen Abhängigkeiten, Kritikalität und Risikofaktoren zu priorisieren. So plante das Team in Abstimmung mit allen Stakeholdern zuerst unkritische Anwendungen für den Wechsel ein, deren Ausfall sich nicht stark auf den Betrieb auswirken würden, sollte es zu Komplikationen kommen. Der große, zentrale Datenbank-Server, auf dem fast alle Datenbanken liefen, stand am Ende der Migrations-Roadmap.

Danach folgte die Migration selbst. Das Team baute eine separate IT-Infrastruktur in der Cloud auf und leitete sukzessive den Traffic auf die neue Plattform um. In dieser Zeit hatte die Migration im Unternehmen Vorrang. Heilmann gab seinem Team größtmögliche Freiheit: "Mein Job war es, dafür zu sorgen, dass das Migrations-Team die Ressourcen aus dem Entwicklungsbereich bekommt, die es braucht und dafür zu sorgen, dass sie an alle Aspekte des Projekts denken."

Der Fortschritt wurde in einem "Burn-Down-Chart" festgehalten, so dass Heilmann stets sehen konnte, an welchem Tag welcher Teil der Infrastruktur migriert wurde. Passierte dort länger nichts, hielt er mit dem Team Rücksprache.

Der Prozess war iterativ und aufeinander aufbauend konzipiert: Aufgrund der Erfahrungen mit den ersten unkritischen Anwendungen, die verschoben worden waren, klassifizierte das Team Apps und Probleme. Kam es bei einer Anwendung zu einem Problem, wurde ein Rollback durchgeführt und das Problem gelöst. Anschließend identifizieren die Mitarbeiter Anwendungen gleicher Klasse und automatisierten für deren Migration die Lösung dieser Problemklasse. So ließ sich bei allen kommenden App-Migrationen dieser Fehler vermeiden.

Mit fortschreitender Erfahrung wurden auf diese Weise immer mehr Migrationsprozesse in Skripten automatisiert, was die Geschwindigkeit steigerte. Nachdem etwa zwei Drittel der Infrastruktur migriert waren, galt es oft nur noch, verschiedene Skripte nacheinander auszuführen, die Ergebnisse zu überprüfen und drei oder vier Konfigurationen anzupassen.

Dieser Automatisierungsgrad kam Heilmann und seinem Team schließlich auch bei der Datenbank zugute, die in kleinen Teilstücken in die Cloud verschoben wurde. Das letzte große Teilstück folgte am ersten Novemberwochenende 2019 und der letzte Server im Rechenzentrum wurde abgeschaltet.

Nach der Migration befindet sich Aroundhome nun in der dritten Phase. Im Frühjahr 2020 will Heilmann das Autoscaling der Cloud-Infrastruktur verbessern, Kubernetes einführen und die verschobenen Anwendungen für die Cloud-Welt optimieren. Zudem soll die gesamte Produktivlandschaft als Testumgebung für die Entwicklung nachgebaut werden.

Lessons Learned und Benefits

Für Heilmann fußt der Erfolg des Projekts auf der agilen DevOps-Struktur seines IT-Teams, kurzen Feedback-Zyklen und dem Motto: "Alles automatisieren, was sich automatisieren lässt". Das inkrementelle Vorgehen bei der Problemlösung gab der Migration die Geschwindigkeit, die er veranschlagt hatte.

Zudem sei die ständige Kommunikation mit allen Beteiligten zentral gewesen. Heilmann nutzte regelmäßige "Tech Talks" für Fortschrittsupdates der Migration an die gesamte Mannschaft. Zusätzlich gab es regelmäßige Abstimmungen mit den Stakeholdern. Darin wurden Status, Benefits, Probleme und Kapazitätsanforderungen der Migration besprochen. Dadurch holte er nicht nur die Produktverantwortlichen an Bord. Auch bisher unbeteiligte Entwickler kamen auf das Migrations-Team zu und fragten, ob sie unterstützen konnten.

Auf betrieblicher Seite bietet die Cloud durch ihre Availability Zones und Skalierbarkeit Schutz vor Totalausfällen. Die Datenbank ist nun weniger Anfällig für Leistungseinbrüche durch rechenintensive Anwendungen. Statt auf einem Server laufen die Datenbanken in der Cloud auf unterschiedlichen Services. Steht eine Datenbank unter Last, sind die anderen und die jeweiligen Anwendungen davon nicht mehr beeinträchtigt.

Aroundhome | Cloud-Migration

Branche: HandelHandel
Mitarbeiter: Projekt Kernteam (2 Mitarbeiter), Unterstützung durch gesamtes Betriebsteam (6 Mitarbeiter) sowie bei Bedarf Entwickler aus den Entwicklungsteams
Zeitrahmen: 3 Monate
Produkte: IT Infrastruktur, AWS
Dienstleister: Zeitweise Unterstützung durch AWS Solution Architects
Einsatzort: Deutschland
Top-Firmen der Branche Handel

Zur Startseite