L'amour est dans le Cloud – Compte-rendu du Talk de Pascal Martin à La Duck Conf 2020

A l'occasion de la DuckConf 2020 Pascal Martin ingénieur DevOps Chez M6 est venu nous présenter la migration de 6play vers le cloud. Un talk passionnant donné par un passionné. Ci dessous le compte rendu de L'amour est dans le Cloud.

Allô Patron? on est mal, très mal !

Les soldes commencent bien pour votre entreprise, les commandes affluent, vous êtes content jusqu’à ce que votre site de ventes en ligne s’écroule sous la charge. Vite il faut racker un serveur dans le Datacenter. Top chrono il vous faudra entre 1 et 5 semaines pour le commander, le recevoir et l’installer. Adieu les soldes d’hiver, disons que vous avez juste anticipé les travaux pour les soldes d’été.

En attendant vous pouvez peut-être trouver l'inspiration de votre prochain business en regardant Qui veut être mon associé? sur 6play. Ou encore mieux en regardant le replay de la Duck Conf l’amour est dans le cloud qui vous racontera comment 6Play est passé dans le cloud.

https://youtu.be/xLELSIEt2xA

Les petits contes de la 6Play

Il était une fois une entreprise qui a avait, comme beaucoup d’autres à l’époque, sa propre salle dans un Datacenter. Elle achetait ses propres serveurs, son matériels réseau et payait une jolie facture d'électricité pour le faire tourner. Puis un jour, elle s’ouvre à l’international, des nouveaux utilisateurs affluent, le trafic augmente, le volume de stockage aussi. Ça marche tellement bien que les CPU du Datacenter tournent à plein régime. Ils atteignirent certains soirs des niveaux à faire rougir les plus grands dictateurs du monde le lendemain d’une élection (98% voire 100%). Disons que ça commence à bien chauffer. La charge été en dents de scie, des pics à certaines heures et certaines périodes de l’année. Néanmoins il fallait bien planifier pour le meilleur ce qui avait pour conséquence d’avoir des serveurs allumés et qui ne faisaient rien pendant certaines périodes. Il fallait trouver une solution.

6Play a trouvé son salut dans le cloud AWS. Plein de services managés à disposition pour apporter la souplesse et l'élasticité recherchées pour faire face à l’augmentation de charge, notamment lors d'événement spéciaux comme des émissions à succès ou certains matchs de football. Les services managés sont pilotés via Terraform et chaque projet est devenu responsable de sa propre infrastructure. Les applications sont dockerisées pour permettre une isolation (le déploiement d’une appli A n’impacte pas l’appli B) et assurer la reproductibilité du déploiement (un pod de l'application B qui se lancerait en réponse à un pic de charge à 21h doit exécuter la même version de l'application déployée à 10h). Se pose alors la question de comment scaler le nombre de conteneur?

Pour ne pas avoir chaud au Kube comme dirait l’autre il vaut mieux choisir un orchestrateur de conteneurs qui tient la route, voire tient le podium du marché. Le choix de Kubernetes s’est imposé même si, à l’époque (2017) Amazon EKS, n’était pas disponible à Paris.

La migration comme elle vient

Pour migrer dans le cloud sans se mettre en danger, il faut du temps. Chez M6 ils ont commencé fin 2017 par une appropriation des outils et des méthodes (Services AWS, Kube, CI/CD…) sous forme de travaux de R&D. Tester pour voir comment et pourquoi ça ne marche pas. IIs ont adopté une approche progressive qui permet d’apprendre sans tout casser non plus. il fallait migrer par petit bout les applications. Cela a permis d'expérimenter le set-up technique (AWS, Kubernetes) et la montée en compétences des équipes. Neuf mois plus tard ils ont accouché d’une première application dans le cloud.  C’est bien connu, les petits ruisseaux font les grandes rivières. Après tout, les gens réapprennent presque à faire de l’informatique dans le cloud. Pendant ce temps la vie ne s'arrête pas, le développement des produits continu. La migration vers le cloud s’est intégrée au travail de tous les jours.

2019 a été l’année de la fiabilisation et de la migration d’applications plus complexes et des applications qui dépendent des services managés. Les applications (client facing) désormais migrées, la facture augmente, les premières optimisations de coûts ont eu lieu.

2020 sera l’année du dernier épisode de l’amour est dans le cloud. C’est le temps de la migration des APIs internes et des backoffices. Le “On-Prem” sera bientôt qu’un vieux souvenir. Une nouvelle vie commence.

Ocean's 6

Dévaliser un Datacenter ça se prépare. Il faut une méthode, une bonne équipe et des répétitions. Alors comment ils ont fait chez M6? Les tâches ont été réparties entre les équipes : une équipe OPS pour l’infrastructure de base, des équipes Dev pour l’adaptation des projets. Ensemble ils réalisaient les tests de performance. En plus ils étaient accompagnés et coachés par une équipe DevOps. Dans chaque projet c’est la même recette, un dossier .cloud/ avec toute la configuration à déployer. Chaque environnement est créé via script avec terraform.  Seules les variables de dimensionnement changent entre dev, staging et prod. Le déploiement applicatif en production est fait avec un pipeline Jenkins. Et la recette miracle pour ne pas se faire prendre?

On y va progressivement pour valider la tenue de la charge avant de tout basculer. Il faut valider, dimensionner, redimensionner, ajuster: CPU, RAM, réseau, process….

1. Créez l’image de l’application on-prem sur le cloud
2. Testez la par un accès direct pour valider qu'elle fonctionne
3. Passez à des vrais utilisateurs et déviez une petite portion du trafic vers le cloud (1%)
4. Augmentez progressivement le trafic vers le cloud (5%, 10%, 20%....)
5. A 100% attendez de valider que ça tiens bien la charge avant de débrancher le on prem (c’est votre issue de secours)
6. Quand vous aurez validé que l'application fonctionne correctement dans le cloud et que l'élasticité recherchée est bien là alors vous pouvez débrancher l'application on-prem. Bravo et bienvenue dans le cloud. Personne n’a rien vu, vous pouvez revendre tranquillement un serveur du Datacenter on-prem

L’exemple mentionné ici concerne une application avec plusieurs serveurs nginx+php et Varnish pour faire le load-balacing et le caching HTTP. Le HAProxy a été ajouté pour dévier le trafic . D’autres exemples sont cités dans la conférence. Ils suivent globalement la même recette..

Résultat: ça tient bien la route, la scalabilité et l’élasticité recherchées sont au rendez-vous. Mais dans le cloud tout se paye, la facture scale très très bien aussi. Finalement c’est peut-être bien AWS qui a réussi le casse du siècle.

Episode final: M6 l’ascension du cloud

Désormais tout nouveau projet va directement dans le cloud.

C’était une bonne idée de choisir Kubernetes, il était du bon côté de la force. C’est un outil riche et complexe, Il faut apprendre à l'appréhender. Pour cela vous aurez besoin d’une équipe de coachs DevOps, elle aidera aussi à identifier les bon services managés à utiliser.

Ne cherchez pas à faire parfait dès le début, ça ne marche pas. Il faut avancer à petit pas. S’améliorer et progresser ça prend du temps! Une migration vers le cloud impacte les produits et les roadmaps en cours. Vous aurez besoin d’un soutien fort du management pour fédérer et aligner les planètes.

En somme migrer dans Le Cloud n’est pas un « projet technique » mais ça vaut le coup/ coût.

Si vous souhaitez en savoir plus sur l’histoire de cette migration vers Le Cloud, AWS et Kubernetes, Pascal Martin écrit un livre nommé “Le Plan Copenhague”. Il y partage son retour d’expérience et présente les choix et compromis qui ont été effectués tout au long de ce voyage. Plus d’informations sur https://leanpub.com/6cloud/