Die Corona-Pandemie hat vielen Unternehmen die Notwendigkeit vor Augen geführt, das Tempo ihrer Digitalisierung zu erhöhen und die Migration in die Cloud zu beschleunigen. So entschied sich das deutsche E-Commerce-Unternehmen myToys von seiner On-Premises-Infrastruktur zu AWS zu wechseln.
Mit dem Wissen, dass während des Prozesses der Cloud-Migration eine Vielzahl von unterschiedlichen Observability-Tools integriert werden muss, ging myToys außerdem eine Partnerschaft mit New Relic ein und nutzte deren Observability-Lösung, um sicherzustellen, dass alles richtig überwacht und integriert wird. Aus der Migration in die Cloud und dem Einsatz von New Relic zog das Team fünf Best Practices:
Best Practice #1: Ein sinnvolles Pilotprojekt wählen
Grundsätzlich gilt, dass man bei der Migration von Anwendungen in die Cloud klein und einfach anfangen sollte. So kann das Team auf risikoarme Weise lernen, Fehler machen und Vertrauen für die Migration größerer, wichtigerer Anwendungen gewinnen.
MyToys verfügte jedoch bereits über ein Team mit einiger AWS-Erfahrung, und wollte außerdem einen deutlich sichtbaren Erfolg präsentieren, der einen klaren geschäftlichen Nutzen so früh wie möglich aufzeigt. Deshalb entschied das Unternehmen sich, gleich mit der Anwendung mit dem höchsten Wert und dem höchsten Risiko als Pilotprojekt zu beginnen.
Best Practice #2: Großzügige Puffer im Zeitplan einkalkulieren
Dieser Tipp gilt für viele Bereiche in denen Zeitpläne erstellt werden, aber die Erfahrungen von myToys zeigen, dass besonders im Bereich Cloud Migration ein großer Puffer von besonderem Nutzen ist.
Selbst bei einem MVP-Projekt, das sich auf ein System konzentriert, das bereits gut bekannt ist, sollte nicht unterschätzt werden, wie lange die Migration in eine neue Umgebung braucht.
Best Practice #3: Auswirkungen auf den Kunden messen
Das Team hatte zu Beginn intern vereinbart, den Datenverkehr nur dann vom lokalen System auf die migrierte Anwendung in AWS zu verlagern, wenn nachgewiesen werden konnte, dass sie über einen 14-tägigen Testzeitraum mindestens die gleiche Konversionsrate wie das lokale System erzielte. Das interne Teamziel war es, eine noch bessere Konversionsrate zu erreichen.
Zunächst musste das Problem der unterschiedlichen Observability Tools gelöst werden. Es war sich zwar auf die Konversionsmetrik geeinigt worden, aber es wurde nicht untersucht, wie die Metriken zwischen lokalem System und AWS erfasst und verglichen werden sollten. Als das Pilotprojekt anfing, 1 % des Datenverkehrs anzuziehen, war klar, dass unterschiedliche Informationen über mehrere Tools gesammelt wurden, ohne die Daten genau vergleichen zu können.
Um Vergleiche anstellen zu können, wurde das Observability Tool New Relic One zur Unterstützung von A/B-Tests in Vorbereitung auf die 14-tägige Testperiode verwendet. New Relic half dabei, sowohl funktionale als auch nicht-funktionale Fehler zu identifizieren, die sich auf Bereiche wie die lokale Empfehlungsmaschine auswirkten und dazu führten, dass Produktdetailseiten nicht effizient generiert wurden und langsam luden. Mit Hilfe von New Relic konnten iterativ Probleme gefunden und behoben und die Systeme weiter optimiert werden.
Nach diesen Bemühungen wurde das Ziel, die gleiche Konversionsrate zu erreichen, übertroffen und sogar ein leichter Anstieg der Konversionen auf AWS erzielt. Dies gelang vor allem durch die Verbesserung des Kundenerlebnisses, indem die Zeit bis zum ersten Besuch um 20 % verkürzt und damit die Absprungrate verringert wurde.
Best Practice #4: Alles früh im Prozess instrumentieren
Nachdem das Team festgestellt hatte, dass es über unterschiedliche lokale und AWS-Tools verfügte, deren Metriken nicht miteinander verglichen werden konnten, instrumentierten sie die wichtigsten lokalen Dienste mit New Relic. Dies brachte einen unerwarteten Vorteil mit sich: Es verbesserte das Wissen und Verständnis für die lokalen Services. Jetzt verfügte das Team über eine automatisch generierte Karte aller Services und Abhängigkeiten, die für die Planung der restlichen Migration verwendet werden konnte. Damit war zwar das anfängliche Dilemma gelöst, dass Metriken zwischen den beiden Umgebungen nicht verglichen werden konnten, es ergab sich allerdings ein neues Problem.
Die Systeme, die zu AWS migriert waren, kommunizierten über das öffentliche Netzwerk mit den Systemen, die noch vor Ort liefen. Dies führte zu einer zusätzlichen Latenz und Belastung der Firewall-Hardware. Um dieses Problem zu beheben, wurde AWS Direct Connect verwendet und eine bessere Firewall-Hardware bereitgestellt. Der gesamte Beschaffungs- und Einrichtungsprozess dauerte etwa 1,5 Monate, wodurch sich weitere Lasttests verzögerten.
Die Instrumentierung der lokalen Anwendungen und die Einrichtung von Direct Connect zu einem früheren Zeitpunkt im Projektplan hätte es ermöglicht, sie parallel durchzuführen.
Best Practice #5: Produktverantwortung nach der Migration planen
Die richtige Teamstruktur zu finden, erwies sich am Ende als die größte Herausforderung während der Migration. Es musste festgelegt werden, wie vom Konzept der Erstellung eines MVP zur Verteilung der Ownership übergegangen werden konnte, sobald die Anwendung in AWS betriebsbereit war.
Für die Pilotmigration wurde eine Task Force eingesetzt, die sich aus Mitgliedern aller anderen Teams zusammensetzte. Dies funktionierte sehr gut für den MVP-Aufwand, aber nicht mehr, sobald das System in Betrieb war.
Es brauchte ein Modell, bei dem das während der Migration gewonnene Wissen nicht in anderen Teams verstreut wurde. Dies war besonders wichtig, da das Ziel darin bestand, mehr als 80 % der Anwendungen innerhalb eines Jahres auf AWS zu migrieren.
Um das Problem der Ownership zu lösen, wurde der Ansatz "You build it, you own it" (grob übersetzt: “Du baust es, du bist verantwortlich”) verfolgt. Jedes Team, das sich aus einem Product Owner und mehreren Ingenieuren zusammensetzt, übernimmt die Verantwortung für die Systeme, die es migriert. Dieser Ansatz hat sich während der gesamten Migration als erfolgreich erwiesen und ist durchaus auch für andere Unternehmen empfehlenswert.
Vorwärts mit der Cloud-Migration
Die Erfahrungen und Erfolge mit dem Pilot-MVP gaben dem Team schlussendlich das Vertrauen und die Fähigkeiten, auch den Rest der Systeme auf AWS zu migrieren. Das Ergebnis ist, dass heute innerhalb von Minuten, angepasst an den Traffic, skaliert werden kann. Und fast noch wichtiger:Es gibt eine klare Strategie für die vollständige Automatisierung der Skalierbarkeit in der Zukunft.
