Guides Essentiels
Voir tous les articles de ce guide
Projet IT
Cet article fait partie de notre guide: Apprendre Kubernetes et créer son propre labo expérimental

Routard.com : un passage au Cloud par étape qui mène à Google Cloud et Kubernetes

Le site Web du guide de voyage est passé d’une infrastructure bare-metal peu évolutive à une architecture en micro-services soutenue par Google Cloud et Kubernetes. Le CTO a opté pour une migration en douceur. Il revient sur son approche.

Cyrille Chausson
par
Publié le: 08 juin 2018

Passer d’une infrastructure bare-metal sur site peu évolutive à une infrastructure entièrement cloud pour mettre en place une architecture en micro-services n’est pas une phase simple et il convient de procéder par étape. C’est l’un des conseils donnés par Philippe Boblet, le CTO de Routard.com, site web du guide touristique édité par Hachette, bien connu des voyageurs français. Ce site, qui totalise plus de 5 millions de vues par mois, reposait jusqu’alors sur une infrastructure maison, composée d’une vingtaine de serveurs blade dépassés, que la virtualisation n’avait pas encore touchée, conte le responsable technique. A cela s’ajoutaient de lourds processus ITIL, des moyens limités en matière de monitoring. Limitées également était les capacités de résilience.  « Il était ainsi temps de changer », lance donc Philippe Boblet.

Très vite, le choix du cloud est apparu, car « nous souhaitions miser sur les API (et la décomposition des applications sous la forme de services, NDLR) et gagner en capacité d’échelle ». LeRoutard.com est en effet sujet à des pics de trafic saisonniers, lorsque se préparent les vacances. « Nous voulions pouvoir changer de calibrage sans délai », ajoute-t-il. Google Cloud a ainsi été préféré à AWS pour répondre à ces besoins.

Si Philippe Boblet a eu une expérience précédente avec le cloud de Google, il estime que « son accessibilité et la lisibilité de ses API » sont supérieures à celles proposés par les autres fournisseurs de services cloud. Mais surtout, comparé à AWS, par exemple, Le Routard avait déjà à l’esprit l’idée de basculer vers une architecture centrée sur les services et considérait les micro-services et les containers comme un tandem de choix. La proximité de Google avec Kubernetes a ainsi pesé dans la balance.

Epaulé par Skale-5, intégrateur spécialisé dans le monde Google Cloud, Le Routard.com a toutefois préféré minimiser les effets de ce changement radical en appliquant les principes d’une migration par étape. « Si nous savions que c’était techniquement faisable, il y avait également un caractère humain  à prendre en compte dans les équipes », rappelle-t-il. Deux phases ont ainsi été programmées.

Du « Lift-and-Shift » au natif pour le cloud

La phase 1 a consisté à migrer certes vers le cloud, mais avec le moins de changements tranchés. Une approche de type « Lift-and-Shift » en somme : « on a repris ce qu’on avait en y ajoutant quelques services comme le load balancer », explique Philippe Boblet . « On préfère une procédure "Lift-and-Shift" efficace pour ensuite ajouter d’autres briques », recommande d’ailleurs Eric K’Dual, le CEO de Skale-5.

Cette première migration vers le cloud révèle également au grand jour des problèmes historiques dont les équipes en place n’avaient jusque-là pas connaissance. « Le passage du bare-metal a dévoilé certains problèmes passés sous silence depuis bien longtemps, comme des boîtes noires pour le fail-over ou encore des disques inadaptés. L’arrivée sur le cloud a permis de faire un inventaire », témoigne Philippe Boblet. « Il est important de ne pas présumer de la connaissance de son propre SI. Cette phase en amont (l’inventaire, NDLR) est essentielle », insiste encore Eric K’Dual.

Une fois cette première phase finalisée, Le Routard a  programmé une phase 2 dont l’objectif premier était de décomposer les applications sous la forme de services. Il s’agit donc de se reposer sur une architecture de micro-services, bâtie sur les containers de Google Cloud. Google Kubernetes Engine (GKE) a ainsi été déployé. « Nous avions de multiples services, utilisés à différentes échelles. Nous les avons donc divisés », souligne le CTO du Routard. Cette fragmentation granulaire a également été opérée sur la base de données qui a, elle-aussi, suivi une migration vers SQL Cloud par étape.

Si la phase 1 a nécessité une équipe de 15 personnes (tous les métiers y étaient impliqués), la phase 2 a permis de moins impliquer les métiers simultanément, résume le CTO. Des équipes de 2 à 3 personnes ont alors été sollicitées.

Au final, cette décomposition en services a eu un effet positif sur la roadmap en fluidifiant les cycles de releases, commente-t-il. « Depuis, les développeurs s’intéressent beaucoup plus à ce qui se passe dans l’infrastructure », illustre-t-il.

Mais le passage au Cloud a eu aussi un autre effet : celui de baisser drastiquement les coûts d’infrastructure. Philippe Boblet parle d’une facture allégée de 70%.

Pour approfondir sur Stockage de conteneurs