5 bonnes pratiques pour la migration cloud de myToys

Lorsque j'ai rejoint le groupe myToys en tant que directeur des technologies, la société avait récemment décidé de passer de son infrastructure sur site à Amazon Web Services (AWS). La principale motivation pour la migration vers le cloud était l'échelle et la vitesse. Pour les entreprises comme la nôtre, la culture était de tout avoir sur site, le chaînon le plus faible de l'évolutivité était de dépendre de notre propre infrastructure.

Au cas où vous ne le sauriez pas, myToys fait partie du groupe myToys une entreprise du groupe Otto, et myToys.de occupe la première place des magasins en ligne pour les jouets et les produits destinés aux enfants en Allemagne. En dehors de myToys, la famille de marques du groupe comprend également limango, mirapodo et omonda.

Avec le recul sur notre expérience avec le premier pilote, puis la migration de 80 % de nos autres systèmes vers AWS, je vais résumer ce que nous avons appris en cours de route et transformé en bonnes pratiques pour les entreprises dans des situations similaires à la nôtre.   

1. Choisissez un projet pilote significatif 

La sagesse populaire veut que l'on commence petit et simple lors de la migration d'applications vers le cloud. En suivant cette approche, l'équipe peut apprendre et faire des erreurs à moindre risque et gagner en confiance pour la migration d'applications plus volumineuses et importantes. Toutefois, nous avions déjà une équipe qui connaissait un peu AWS et nous pensions que nous avions besoin d'une réussite très visible qui prouvait une valeur métier claire le plus tôt possible. C'est pourquoi nous avons choisi comme projet pilote de démarrer avec l'application qui avait la plus forte valeur, mais qui présentait aussi le plus haut niveau de risque. Je ne recommanderais pas cette approche aux organisations sans personnel ayant une certaine expérience AWS. Outre les membres de l'équipe avec de l'expérience, nous avons également une culture dans laquelle les personnes sont intrinsèquement motivées d'apprendre rapidement et d'expérimenter avec les nouvelles technologies.        

2. Prévoyez une bonne marge de temps pour votre calendrier     

J'ai appris très tôt dans ma carrière que, quelle que soit l'estimation du temps et des efforts nécessaires pour accomplir quoi que ce soit, il vaut mieux la doubler pour que ce soit réaliste. Nous pensions que parce que l'effort requis pour le projet pilote planifié était de type « produit minimum viable (MVP) », nous n'avions pas besoin d'inclure trop de marge dans notre objectif de lancement.  Nous avions tort. Cela a été la plus grande leçon que nous avons tirée de cet effort : même pour un projet MVP focalisé sur un système que vous connaissez déjà très bien, ne sous-estimez pas le temps qu'il vous faudra pour migrer vers un nouvel environnement. Ajoutez une marge généreuse à votre objectif de lancement.  Pensez au projet comme si vous construisiez une maison. L'entrepreneur doit coordonner de nombreuses personnes et équipes différentes qui s'occupent de tâches spécifiques dépendantes du temps tout au long du projet. Il y aura toujours des risques et des délais inattendus avec ce type de projets. C'est pareil avec la technologie.           

3. Soyez certains de pouvoir mesurer l'impact sur les clients       

Nous avons établi un accord avec l'entreprise de ne pas déplacer le trafic de notre système sur site vers l'application envoyée sur AWS sauf si nous pouvions démontrer qu'elle obtenait au moins le même taux de conversion que le système sur site pendant une période test de 14 jours. Bien qu'elle n'ait pas été dévoilée à l'entreprise, l'intention de notre équipe était de fournir de meilleures performances qui stimuleraient l'augmentation des conversions.  

Nous avons tout d'abord dû résoudre le problème d'outils d'observabilité disparates. Si nous étions d'accord sur la métrique de conversion, nous n'avions pas recherché comment collecter et comparer les métriques entre le sur-site et AWS. Quand notre projet pilote a commencé à attirer 1 % du trafic, nous nous sommes rendu compte que nous collections des informations différentes sur plusieurs outils sans possibilités de comparer précisément les données. 

Comme j'avais déjà utilisé New Relic, je savais que j'allais pouvoir résoudre notre problème. Une fois que les applications sur site et dans le cloud ont été instrumentées, nous avons pu utiliser New Relic de comparer les métriques de référence avec celles de l'application pilote. Nous avons commencé à utiliser New Relic pour soutenir le test A/B en préparation des 14 jours de la période d'essai. New Relic nous a aidés à identifier les bogues fonctionnels et non fonctionnels qui impactent les zones comme notre moteur de recommandations sur site, qui ont entraîné une génération et un chargement inefficaces et lents des pages de détail de produits.  En utilisant New Relic, nous avons trouvé les problèmes de matière itérative, nous les avons dépannés, nous les avons à nouveau testés et nous avons encore plus optimisé nos systèmes. 

Après cet effort, nous avons dépassé notre cible visant le même taux de conversion et généré une légère hausse des conversions sur AWS. Nous avons fait cela en améliorant l'expérience des clients, en réduisant le temps jusqu'au premier octet de 20 % et en réduisant le taux d'abandon.        

4. Instrumentez tout très tôt dans le processus     

Lorsque nous nous sommes rendu compte que nous avions des outils sur sites et AWS disparates et que nous ne pouvions pas comparer les métriques, nous avons instrumenté nos principaux services sur sites à l'aide de New Relic. Nous en avons tiré un avantage important : l'amélioration de nos connaissances et une meilleure compréhension de nos services sur sites. Nous disposions alors d'une carte générée automatiquement de tous nos services et dépendances et nous pouvions l'utiliser pour la planification du reste de la migration.

Bien que cela ait résolu notre difficulté première de comparaison des métriques sur deux environnements, cela a également soulevé un nouveau casse-tête. Les systèmes que nous transférions vers AWS communiquaient sur le réseau public avec les systèmes qui tournaient encore sur site. Une latence et une charge supplémentaires ont été ainsi ajoutées sur le matériel de notre pare‑feu. Pour résoudre ce problème, nous avons utilisé AWS Direct Connect et déployé un meilleur matériel de pare‑feu. Tout le processus d'approvisionnement et de paramétrage a pris environ un mois et demi, ce qui a retardé encore plus les tests de charge.

L'instrumentation de nos applications sur site et le paramétrage de Direct Connect plus tôt dans la planification du projet nous auraient permis de faire de son exécution une activité parallèle.

5. Prévoyez la propriété du produit post‑migration      s

Tout au long de l'effort de migration, notre plus gros défi a été de créer la bonne structure d'équipe. Nous devions déterminer comment passer du concept de création d'un MVP à la distribution de la propriété une fois que l'application a été opérationnelle dans AWS. 

Pour la migration pilote, nous avons utilisé une équipe dédiée (également appelée « groupe de travail ») composée de membres de toutes nos autres équipes. Cela a très bien fonctionné pour notre effort MVP, mais ça s'est arrêté de fonctionner une fois que le système était opérationnel. Ce dont nous avions besoin était un modèle de propriété dans lequel les connaissances gagnées pendant la migration n'étaient pas partagées avec les autres équipes. Cela était particulièrement important parce que notre objectif était de migrer plus de 80 % des applications vers AWS en un an. 

Pour résoudre le problème de propriété, nous avons suivi l'approche qui consiste à exécuter ce que l'on développe. Chaque équipe, composée d'un propriétaire de produit et d'ingénieurs, prend en charge les systèmes qu'elle migre. Cette approche s'est avérée un succès tout au long du processus de migration et je la recommande à d'autres organisations, car elle améliore finalement notre excellence opérationnelle.   

La migration vers le cloud, une décision importante

Notre expérience et notre réussite avec le MVP pilote nous ont donné la confiance et les compétences nous permettant de migrer le reste de nos systèmes vers. Résultat : aujourd'hui, nous pouvons évoluer en quelques minutes en fonction du volume de trafic et nous avons une stratégie pour complètement automatiser l'évolutivité à l'avenir.

Photo fournie par myToys