5 Best Practices von myToys für die Cloudmigration

Als ich meine Stelle als Head of Technology in der myToys Group antrat, hatte das Unternehmen kurz zuvor den Umstieg von einer On-Prem-Infrastruktur zu Amazon Web Services (AWS) beschlossen. Hauptgrund für die Cloudmigration war die Verbesserung von Skalierbarkeit und Geschwindigkeit, denn für Unternehmen wie unseres, zu deren Gründungszeit der On-Prem-Ansatz Standard war, stellt die eigene Infrastruktur oft die größte Hürde in Sachen Skalierbarkeit dar.

MyToys gehört zur myToys Group, einem Unternehmen der Otto Group, und myToys.de ist Deutschlands führender Onlineshop für Spielzeug und Produkte rund ums Kind. Neben myToys gehören zur Gruppe auch die Marken limango, mirapodo und yomonda.

Aus den Erfahrungen mit unserem ersten Pilotprojekt und der anschließenden Migration von 80 % unserer weiteren Systeme zu AWS entstand diese Sammlung von Best Practices für Unternehmen, die sich in einer ähnlichen Situation befinden wie wir damals.   

1. Wählen Sie ein relevantes Pilotprojekt 

Es ist eine Binsenweisheit, dass man bei der Migration von Anwendungen zur Cloud klein anfangen sollte. So kann das Team ohne großes Risiko aus Fehlern lernen und diese beim Migrieren größerer, wichtigerer Anwendungen vermeiden. Allerdings hatten wir bereits ein Team mit einiger AWS-Erfahrung und wir waren uns einig, dass wir einen augenfälligen Erfolg brauchten, der so früh wie möglich einen klaren geschäftlichen Nutzen aufzeigt. Deshalb entschieden wir uns, unsere kritischste Anwendung zum Pilotprojekt zu machen. Diesen Ansatz würde ich Unternehmen ohne jegliche Erfahrung mit AWS allerdings nicht empfehlen. Wir hatten den Vorteil, dass wir nicht nur erfahrene Teammitglieder hatten, sondern neuer Technologie gegenüber ohnehin immer sehr aufgeschlossen sind und eine Kultur des Lernens und Experimentierens fördern.        

2. Planen Sie genug Zeit ein     

Ich habe sehr früh in meiner Karriere festgestellt, dass die meisten Projekte sehr viel länger dauern als ursprünglich geplant und es daher immer eine gute Idee ist, die geplante Zeit grundsätzlich zu verdoppeln. Bei diesem Pilotprojekt waren wir uns sicher, dass es als ein MVP (Minimum Viable Product, also eine minimal funktionsfähige Produkt-Iteration) bis zum Go-Live-Datum keinen großen Puffer erfordern würde.  Da lagen wir allerdings falsch, und das war wahrscheinlich unsere wichtigste Lektion: Selbst bei einem MVP-Projekt und einem System, mit dem man komplett vertraut ist, darf man den Zeitaufwand für die Migration in eine neue Umgebung auf keinen Fall unterschätzen. Planen Sie also einen großzügigen Puffer ein.  Man kann das Ganze mit dem Hausbau vergleichen: Der Bauherr muss zahlreiche verschiedene Handwerker und Teams unter einen Hut bringen, damit alle Bauarbeiten zum richtigen Zeitpunkt und fristgerecht durchgeführt werden, und bei solchen Projekten kann es aus den unterschiedlichsten Gründen immer mal zu Verzögerungen kommen. In der IT ist das nicht anders.           

3. Legen Sie fest, an welchen Kennzahlen Sie den Erfolg festmachen werden.       

Wir vereinbarten, dass der Traffic erst dann von unserem lokalen System in die migrierte Anwendung verlagert würde, wenn wir nachweisen konnten, dass die Konversionsrate in AWS über einen 14-tägigen Testzeitraum mindestens der im On-Prem-System entsprach. Ohnehin hatten wir uns im Team zum Ziel gesetzt, eine noch bessere Performance und somit mehr Konversionen als im alten System zu liefern, auch wenn wir das nicht an die große Glocke gehängt hatten.  

Unser erstes Problem waren die bunte Sammlung unterschiedlicher Observability-Tools. Wir hatten uns zwar auf die Konversionen als Kennzahl geeinigt, aber wir hatten uns nicht überlegt, wie wir diese in On-Prem und AWS erfassen und vergleichen sollten. Sobald 1 % des Traffic über unser Pilotprojekt lief, stellten wir fest, dass sich die Daten, die wir über mehrere Tools sammelten, gar nicht eins zu eins vergleichen ließen. 

Ich hatte zuvor bereits mit New Relic gearbeitet und war mir deshalb sicher, dass wir das Problem damit lösen konnten. Nachdem die On-Prem- und Cloudanwendungen instrumentiert waren, konnten wir nun mithilfe von New Relic die Baseline-Metriken mit denen der Pilotanwendung vergleichen. Wir begannen, New Relic für die A/B-Tests zur Vorbereitung auf die zweiwöchige Testphase einzusetzen. Das half uns, funktionale und andere Bugs zu ermitteln, die sich beispielsweise auf unsere lokal installierte Empfehlungs-Engine auswirkten und dazu führten, dass Produktdetailseiten nicht effizient generiert und zu langsam geladen wurden.  Mithilfe von New Relic konnten wir iterativ vorgehen und gefundene Probleme beheben, Tests dann wiederholen und mit der Systemoptimierung fortfahren. 

Letztendlich haben wir in AWS sogar eine etwas bessere Konversionsrate als On-Prem erreicht. Der entscheidende Faktor hierfür war die Tatsache, dass wir die Seitenladezeit um 20 % verkürzt und die Bounce-Rate gesenkt hatten – was für ein angenehmeres Kundenerlebnis sorgte.        

4. Instrumentieren Sie alles möglichst frühzeitig     

Nachdem wir festgestellt hatten, dass unsere lokalen Systeme und die AWS-Tools keine vergleichbaren Metriken lieferten, instrumentierten wir unsere wichtigsten lokalen Services mit New Relic. Das hatte den unerwarteten Nebeneffekt, dass wir einen umfassenden Einblick in den Aufbau unserer lokalen Services erhielten. So hatten wir jetzt eine automatisch erstellte Übersicht aller Services und Abhängigkeiten, die uns die Planung der restlichen Migration erleichterte.

Kaum war unser ursprüngliches Problem der mangelnden Vergleichsfähigkeit der beiden Umgebungen gelöst, entdeckten wir einen neuen Stolperstein: Die Systeme, die wir nach AWS migriert hatten, kommunizierten über das öffentliche Netzwerk mit den Systemen, die noch immer lokal vor Ort liefen. Das führte zu zusätzlicher Latenz und Auslastung unserer Firewall-Hardware. Mit AWS Direct Connect und besserer Firewall-Hardware konnten wir auch dieses Problem beheben, allerdings dauerten Beschaffung und Setup rund anderthalb Monate, wodurch sich die weiteren Belastungstests verzögerten.

Hätten wir unsere On-Prem-Anwendungen früher instrumentiert und auch Direct Connect früher eingerichtet, hätten wir das Ganze parallel laufen lassen können.

5. Machen Sie einen Plan für die Produktverantwortung nach der Migration      

Die richtige Teamstruktur zu schaffen entpuppte sich als das schwierigste Unterfangen während der gesamten Migration. Wir mussten uns überlegen, wie wir den Übergang vom MVP zur Zuständigkeit für die Anwendung bewerkstelligen sollten, sobald sie in AWS im Einsatz war. 

Für das Pilotprojekt hatten wir speziell zu diesem Zweck ein Team zusammengestellt – quasi eine Taskforce, die aus Fachleuten aus verschiedenen anderen Teams bestand. Für das MVP war das perfekt, aber sobald das System in Betrieb war, war die Lösung nicht mehr gangbar. Ein anderes Modell musste her, damit die während der Migration gesammelten Erfahrungen nicht in den anderen Teams verloren gingen, denn wir hatten uns zum Ziel gesetzt, innerhalb eines Jahres über 80 % der Anwendungen nach AWS zu migrieren. 

Die erfrischend einfache Lösung war die Zuweisung von Zuständigkeiten nach dem Prinzip: Wer es entwickelt, ist auch für den Betrieb zuständig. Jedes Team, bestehend aus einem/einer Produktverantwortlichen und Entwickler:innen, ist somit für die von ihm migrierten Systeme zuständig. Dieser Ansatz hat für uns während der gesamten Migration wunderbar funktioniert. Ich kann ihn nur empfehlen, denn er entpuppte sich nebenbei auch als Gewinn für unsere Operational Excellence.   

Mit der Cloud in die Zukunft

Mit dem Pilot-MVP gewannen wir genügend Sicherheit und Erfahrung, um die restlichen Systeme nach AWS zu migrieren. So können wir das System jetzt in wenigen Minuten entsprechend dem Traffic skalieren, und eine komplett automatische Skalierung ist bereits in Planung.

Foto: myToys