Migration Cloud : comment Back Market est passé d’AWS à Google Cloud

Clément Bohic,
Linkedin
Back Market Google Cloud

Back Market a finalisé le gros de sa migration vers Google Cloud, après quasiment dix ans chez AWS. Retour d’expérience.

Est-ce la dernière fois que Back Market change de cloud provider ? Ses ingénieurs reconnaissent qu’il sera « difficile de revenir en arrière », vu la décision d’adopter massivement des services managés.

Ce ne sera pas chez AWS, son fournisseur historique. Mais chez Google Cloud. Une option que l’entreprise française avait sur ses tablettes depuis un moment – raison pour laquelle elle était restée « cloud-agnostic ».

Il était une fois chez AWS

À ses débuts en 2014, Back Market avait fait appel à un infogéreur. Quatre ans plus tard, le modèle commençait à montrer ses limites. D’ordre technique (pas de service discovery, d’autoscaling, de CDN, etc.), mais aussi organisationnel : sans ressources internes dédiées côté plate-forme, l’infrastructure était une boîte noire.

L’architecture tournait alors sur des VM. Avec deux monolithes : un front en Node.js, un back-end écrit en Python avec Django. Back Market s’appuyait sur Aurora MySQL et Redis, avec une partie Cloudfront + S3.

Pour reprendre le contrôle sur la plate-forme, l’entreprise a décidé de l’internaliser. En restant sur AWS et en misant sur l’écosystème cloud native. « On a voulu déporter énormément de features sur les edges, en mettant d’abord du CDN et [de la sécurité], explique Théotime Lévèque, lead architect. On a entrepris de supprimer les VM, pour conteneuriser les applications et les déployer dans Kube. »

Kubernetes, mais à quelle sauce ?

En arrière-plan, on pensait déjà à Google Cloud et à son offre GKE, alors « relativement mature en comparaison à EKS », qui était en pré-alpha. « On avait aussi notre avis sur le CNI d’AWS », glisse T. Lévèque. Il s’agissait cependant d’agir rapidement pour éviter de resigner un contrat d’engagement avec un autre infogéreur. D’où une exécution de la migration en un mois. Avec un tel timing, ce n’était pas le moment de changer de cloud provider, nous résume-t-on.

C’était sans compter la question des bases de données. Back Market admet qu’on devient « vite dépendant » d’Aurora. Le produit propose un replica lag d’une latence très faible. Lorsque celui-ci augmente, on découvre que les workloads « ne sont pas forcément très tolérants à l’eventual consistency ».
Un customer engineer avait d’ailleurs fait remarquer qu’une migration impliquerait des efforts substantiels à ce niveau. Une mise en garde qui « [sortait] des chemins battus de ce qu’on voit en phase de pre-sales » et qui a « généré une confiance assez importante », selon T. Lévèque.

Du « cloud-agnostic » aux services managés

En 2018, Back Market comptait 100 employés. Cinq ans plus tard, il en était à 700. Avec une trentaine d’équipes, deux niveaux de management supplémentaires… et une stratégie cloud-agnostic qui commençait à coûter cher. Il avait alors cloisonné complètement la plate-forme (80 personnes) et le produit. Une vision « pas très DevOps », mais qui permet aux équipes produit de « rester la tête dans le guidon ».

Au niveau technique, l’opportunité des services managés avait fini par se faire ressentir au niveau des clusters Kubernetes, gérés avec kOps. Au-delà de ses coûts, la maintenance « nous a empêchés de faire le platform engineering et de l’emmener où on voulait, déplore Antonin Mellier, architecte cloud. On avait créé des modules Terraform pour les équipes de dev, fait de la documentation ; sauf que faute de temps, on ne les a pas accompagnés ».

Une partie du SI était déjà chez Google Cloud depuis 2019. En l’occurrence, la plate-forme d’analytics, sur BigQuery. L’alimenter depuis AWS entraînait des coûts de trafic sortant. Encore acceptables en 2023, mais moins tenables en faisant des projections à 10 ans.

Pour augmenter la disponibilité de ses clusters kOps self-managés, Back Market les avait doublés sur chaque région. Il avait aussi ajouté de l’EKS. « Pour pouvoir fournir de l’isolation à nos équipes, la seule solution [envisageable] était de créer un compte AWS, un VPC et un cluster dédié. On s’est donc retrouvé à gérer Kubernetes de deux façons. » Utilisé sur les clusters kOps, Cilium fut aussi déployé sur EKS pour une raison de cohérence. « On se retrouvait donc, même sur un service managé, à opérer nous-mêmes la partie réseau. »

La fin d’un monolithe

Après avoir benchmarké, le choix s’est réduit à deux options : réarchitecturer sur AWS ou passer sur GCP. Les considérations concurrentielles ont pesé dans la décision : en restant chez Amazon, Back Market allait financer indirectement un compétiteur. La « conscience environnementale » a également joué. En tout cas au vu du score CDP, résultat d’une autoévaluation. Tandis que GCP avait la note A depuis 2014, AWS avait encore un F jusqu’en 2020 (puis B en 2023).

Si on en croit les équipes de Back Market, Google propose aussi bien plus sur les outils de mesure d’impact. Y compris dans la littérature et les études menées. Quant à l’expertise acquises sur AWS, ce « n’était pas forcément un problème : d’un cloud provider à un autre, les concepts restent les mêmes, bien que les implémentations soient différentes ».

Back Market étant déjà engagé dans une modernisation de son back-end de monolithe en microservices et dans le rewrap du framework frontal, « on savait qu’on ne pouvait pas empiéter sur les équipes produits », explique Sami Farhat, ingénieur senior : l’équipe plate-forme allait gérer la migration GCP.

Le MLOps traité à part

L’objectif fut de migrer en 6 mois et de déplacer, dans ce contexte, 80 % des coûts d’AWS à GCP. La date de renouvellement du contrat AWS a joué sur le timing : « On savait que tout le temps passé sur GCP, on allait avoir le double run », admet S. Farhat. Aussi Back Market a-t-il « demandé un changement de fonctionnement à des équipes qui ont l’habitude de promettre de la robustesse plutôt que de faire de l’itératif », d’après T. Lévèque. Bilan : « On a eu quelques personnes secouées sur la prise de décision. » S. Farhat en dit autant : « Cette approche est OK pour des personnes tranverses. […] Moins pour des ingénieurs qui sont peut-être parfois perfectionnistes »…

Un PoC fut lancé en mars 2023. Il sollicita 30 personnes à plein temps pendant deux semaines dans les bureaux de Google. Le but : mettre toute la préprod de Back Market sur GCP. Le projet de migration démarra en septembre. Les premières concrétisations intervinrent en janvier 2024 (préprod APAC, puis US et UE). Pour la prod, la démarche s’est échelonnée sur mars-avril. La migration a donc duré un peu plus longtemps que prévu (8 mois, pour une vingtaine de clusters, en comptant ceux en full back et dédiés aux workloads PCI-DSS ; l’infra monte à 40 000 conteneurs). Il reste par ailleurs une petite partie du SI sur AWS : celle associée au MLOps (Amazon SageMaker). Back Market à choisi de « dérisquer » complètement ce volet en le traitant à part (« C’est totalement différent des workloads HTTP, gRPC ou stateless sur du Node.js. »). En attendant, il a mis en place un peering entre ses VPC AWS et GCP.

Qui dit AlloyDB dit Postgre

Avec le passage à GKE, les clusters kOps self-managés n’existent plus. Back Market n’opère plus la partie réseau (il s’appuie sur Dataplane V2 et délègie la gestion à GCP). Plus non plus de MySQL : avec AlloyDB (plus ou moins l’équivalent d’Amazon Aurora), il a fallu passer sur PostgreSQL. « Pour nous, c’était une contrainte »… et surtout le principal défi, affirment les ingénieurs. Même s’il faut approfondir les benchmarks, les résultats sont jusqu’ici encourageants, et de façon constante, assure T. Lévèque.

L’intéressé ne le cache pas : sur le plan global, il n’y a eu « presque aucun gain » d’un point de vue contractuel. « Ce n’est pas le changement de cloud provider en lui-même qui va nous permettre de faire des économies. C’est la modernisation qu’on fait pendant la migration. »

Back Market a profité de la migration pour intégrer Crossplane à son écosystème : « Désormais, les devs peuvent déployer leurs workloads en utilisant les API Kube, mais aussi provisionner l’infra GCP avec. »

De Terraform à Crossplane

Très tôt, l’entreprise avait adopté Terragrunt, surcouche à Terraform permettant de gérer plus simplement les dépendances entre les modules. « Après quelques années, on s’est dit que ça nous ajoutait [de la] complexité, clame T. Lévèque. Il s’agissait surtout de ne pas tout gérer de manière immutable (distinguer infra et infrastructure lifecycle). Crossplane a constitué une réponse à cette problématique. L’outil utilise du YAML, très proche d’une définition de ressource Kubernetes : « Ça nous fait gagner pas mal de temps de garder la totalité des définitions d’un écosystème au même endroit et sous une même forme ».

Il n’est pas question de migrer tout le Terraform vers du Crossplane, mais plutôt les ressources des équipes produits, « genre base de données Redis ; que ce soient eux qui contrôlent et voient clairement les capacités de leurs ressources », selon S. Farhat.

* Back Market a témoigné de ce projet à la Devoxx France (avril 2024) et au Google Cloud Summit (mai).

Illustration © pixabay via Pexels