Thought Leadership
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.
