Aller au contenu

Retour sur trois voyages vers le Cloud avec les témoignages de Compte Nickel, HiPay et Lesfurets.com

Focus sur trois stratégies de migration vers le Cloud avec Lesfurets.com, Nickel et HiPay.

Il y a quelques mois, SFEIR organisait une table ronde en partenariat avec Google Cloud et Tech.Rocks, sur le thème de la migration vers le Cloud et de l'approche Cloud native. Les témoignages des entreprises Lesfurets.com, Compte Nickel et HiPay ont permis d'éclairer sur les différentes stratégies de voyage adoptées vers le Cloud, mais également sur les avantages et les problèmes rencontrés lors de cette transition.

La migration vers le cloud est souvent présentée comme un processus simple et naturel, mais en réalité, elle est unique à chaque entreprise.

Les objectifs de la migration sont d'assurer en priorité :

  • la simplicité
  • le time-to-market
  • la provision d'infrastructure
  • la liberté de choix et d'innovation.

Trois stratégies de migration sont alors possibles :

  1. le lift and shift
  2. la migration en re-hostant les applications , les données avec l'intégration de services cloud
  3. la modernisation des applications.

Ce qui était tout particulièrement intéressant ici était de comparer les trois entreprises présentes dans leurs différentes stratégies de migration vers le Cloud.

  1. La société Lesfurets.com a migré ses applications monolithiques sur le Cloud, tout en gardant l'infrastructure telle quelle. La reconstruction des apps se fera dans un second temps. On ne peut casser  une application de 10 ans en un claquement de doigts ! Cela correspond à la stratégie n°1, avant l’aller vers une stratégie mixte n°2 et n°3.                                                                                               « Nous étions déjà en livraison journalière. Cela nous a donné une appétence sur le recrutement. On avait des systèmes plus difficiles à scaler, difficile à mettre en place de nouveaux services. Plus facile de pouvoir créer de nouveaux services sur le cloud que sur un environnement On premise. L’avantage du cloud est de réduire les délais et nous donne plus de souplesse.» Geoffrey Berard (Deputy CTO Lesfurets)                                      
  2. HiPay a elle, réalisé un replatforming sur la partie donnée, avec pour objectif d'être full Cloud. La stratégie n°3 a son état pure !                               « Nous avons des équipes (techniques) qui grossissent, avec des besoins en ressources, les demandes étaient très longues auprès des admins. Cela encourage à rester sur des technologies existantes. Laisse peu de place à l’innovation. Voilà pourquoi on part sur du cloud computing. On a une forte croissance, la plateforme doit monter en charge, le Cloud apporte cette scalabilité ». - Johan Protin (Lead Software - HiPay)              
  3. Compte Nickel a choisi une approche entièrement serverless pour automatiser le déploiement et la fourniture de ressources et de services Cloud lors de la migration de son infrastructure. Une combinaison entre les stratégie n°1 et n°2. « Le but était de monter des données dans une base de données sur une base sans la configurer. On fait juste du requêtage de données. » - Paul Marcombes (Lead Software Engineer - Compte Nickel)

Que se cache derrière ces trois stratégies de migration?

  • Le lift and shift est la migration la plus simple, où l'on utilise le Cloud pour remplacer purement et simplement l'infrastructure de l'entreprise.
  • Le rehosting permet d'utiliser certains services Cloud sans que les applications ne changent fondamentalement.
  • La modernisation est la migration la plus radicale, où les applications sont adaptées, optimisées et construites sur le Cloud.

Enfin, il est important de bien déterminer l'utilisation du Cloud, s'il doit être optimisé pour les projets en production ou uniquement pour les nouveaux développements. Souvent, les entreprises mixent les deux approches. Mais le Cloud-first peut être imposé pour les nouveaux projets.

« Nous avons reconstruit notre data plateforme avec une approche cloud native. Notre objectif étant de migrer notre infrastructure et nos codes sur le cloud en moins d’un an, nous avons pris le lift and shift. Nous avons packagé avec Docker pour des déploiements plus efficaces mais globalement, l’application reste la même. C’est un monolithique qui a 10 ans. Plus tard, nous pourrons la découper pour aller éventuellement vers du cloud functions, serverless. » explique Geoffrey Berard (Deputy CTO - Lesfurets)

« Dans un premier temps, nous avions deux équipes pour reconstruire les applications sur le cloud. Cela a permis de développer en interne une stack GCP. Dans un second temps, nous nous sommes posés des questions sur le replatforming de la partie donnée. Il fallait tout reconstruire. Nous avons mis les moyens (nécessaires) dessus. Nous commençons à être full GCP. Suite à ces succès, d’autres équipes internes ont décidé d’aller sur le cloud. Cela se joue sur des opportunités. Tous nos nouveaux projets sont lancés sur le cloud. Nous sommes cloud first. On privilégie le serverless first. » explique Johan Protin (Lead Software - HiPay)

« Au départ, nous sommes partis sur du full serverless puis au fur et à mesure, on a déployé des applications internes. Maintenant, nous avons une dizaine d’apps qui sont serverless. Pour déployer une application, nous avons juste les pré-requis Python et rien d’autre à s’occuper. », conclut Paul Marcombes (Lead Software Engineer - Compte Nickel)

Un voyage magique: entre théorie et pratique, la réalité est toute autre !

Migrer vers le Cloud peut sembler magique, mais cela nécessite du temps, un budget et des compétences. Il s'agit d'un projet IT qui ne doit pas être pris à la légère puisqu'il demande l'adhésion des équipes de développement et d'opérations ainsi que du soutien de la direction, surtout lorsqu'il s'agit de migrer depuis un système sur site On-premise vers le Cloud !

Le Cloud est une vision à long terme. Il est dangereux de croire que la migration se fera sans difficultés ou sans complications. Il est essentiel d'accompagner les équipes, de renforcer leurs compétences, de les former et de s'appuyer sur des experts externes pour guider et conseillers sur les modifications techniques et les choix de services.

L'une des difficultés majeures lors d'une migration vers le Cloud est de choisir la bonne plateforme ainsi que les services à utiliser pour chaque type d'actif, de définir les outils appropriés et de mettre en place de nouveaux processus. Certaines plateformes Cloud offrent plus de 300 services différents avec une multitude d'options, ce qui rend complexe la tâche de sélectionner les services appropriés pour chaque application ou usage.

Sur le plan technique, la migration vers le Cloud n'est pas la partie la plus difficile. Cependant, il est important de prendre en compte les contraintes de l'entreprise et de définir un rythme de migration adapté. Il n'est pas possible de passer d'une application monolithique à une architecture micro-services en appuyant simplement sur un bouton. Une refonte complète de l'architecture et du code est alors nécessaire.

En général, les entreprises commencent par migrer une application à la fois, puis continuent avec les autres applications progressivement.

Le "double run" est un autre problème récurrent, lorsque les données et les applications s’exécutent à la fois en On-premise et sur le Cloud, le temps que la migration soit totalement opérationnelle. Cela implique un double problème pour les équipes pour maintenir les deux exécutions au même niveau. Goutte d’eau qui met le feu aux poudres: ce double run impacte forcément le budget !

« C’est un chantier. Il faut faire adhérer le cloud aux équipes. Suite aux succès des premières équipes, nous avons décidé de valider l’usage du cloud en interne. On a identifié un stack de compétence à acquérir. Il faut mettre en place des formations. Pour aller vite, il faut aussi des compétences externes. Cela prend du temps. Il y a toujours un enjeu business, la plateforme doit fonctionner. Il y a le double run que l’on veut limiter. La direction doit comprendre les enjeux : les coûts, l’infrastructure, l’avenir. Enjeux sur la productivité des équipes : livrer plus vite, améliorer l’expérience développeur. Il y a des avantages techniques (du Cloud). », explique Johan Protin

« Le change management peut être compliqué car les paradigmes ne sont pas les mêmes. Typiquement, notre application, on livre tous les jours les 7 tomes d’Harry Potter. Cela a des coûts de compilation, de déploiement. Les équipes ne passent pas du jour au lendemain d’un monolithique qui a 10 ans à quelque chose de beaucoup plus moderne. Il faut s’assurer qu’ils soient formés et on doit modifier les processus. L’accompagnement au changement est important. Il y a un énorme volume d’informations sur la plateforme. C’est facile de s’y perdre. Il faut se repérer dans l’offre. Il faut être guidé pour savoir quoi prendre, éviter les écueils.», explique Geoffrey Berard.

« Nous avons commencé par créer une première application, puis une seconde, etc. Nous nous sommes fait accompagner à deux moments clés : mettre en place une organisation du code propre, usage de Terraform. Quand nous avons un besoin sur un nouveau produit, un nouveau service, nous nous faisons accompagner. », complète par sa part Paul Marcombes.

Si les équipes ne sont pas déjà agiles, ou DevOps, le Cloud va apporter cette dimension agile et d’automatisation avec le CI/CD et la philosophie DevOps.

Gare aux coûts !

Bien que la promesse initiale était d'un coût inférieur à l'informatique interne, la réalité a montré que le Cloud n'était pas toujours plus compétitif en termes de dépenses. Toutefois, il est crucial de ne pas se focaliser uniquement sur l'aspect financier. Au début, les équipes ont tendance à surdimensionner les instances et les ressources pour éviter les mauvaises surprises, ce qui se traduit par des coûts élevés. Cependant, dans une deuxième phase, les équipes peuvent optimiser les ressources allouées, ajuster les quotas, fixer des seuils de ressources et suivre les dépenses service par service. La modernisation des applications monolithiques permet également de mieux utiliser les services Cloud et de mettre fin aux services inutilisés. L'autoscaling est une fonctionnalité pratique pour augmenter rapidement la capacité et réduire les coûts lorsque la charge diminue. Le Finops est crucial pour surveiller les coûts du Cloud. Il est important de sensibiliser les équipes aux coûts du Cloud, car les services sont facturés à l'usage et la tarification varie d'un service à l'autre. Cette sensibilisation dépend de la maturité des projets Cloud et des équipes. Mais le budget ne doit certainement pas être un frein à l'adoption du Cloud !


Infrastructure as Code: La bonne idée d'automatiser !

Le Cloud, Kubernetes, le Cloud native et les conteneurs permettent d'automatiser l'infrastructure et le déploiement des applications et des services. Cette automatisation est rendue possible grâce à l'Infrastructure as Code (IaC). Chez Compte Nickel, Terraform a été choisi dès le départ pour créer un modèle d'infrastructure pouvant être répliqué facilement en cas de besoin. Les équipes n'utilisent presque pas la console de Google Cloud Platform, tout étant géré en IaC.

Mais si vous souhaitez passer rapidement au Cloud, il est préférable d'aller vite sans chercher à optimiser ou automatiser chaque étape. L'IaC peut être utilisé dans une deuxième étape de votre transition. Même si votre infrastructure Cloud est déjà en production, l'IaC peut être ajouté pour offrir une agilité supplémentaire.

Au-delà de l'existant !

HiPay vise à devenir une entreprise full Cloud dans les 2 à 3 prochaines années. Grâce au lift and shift, les premiers déploiements ont été réalisés rapidement. Cependant, il est maintenant nécessaire de poursuivre les efforts pour adapter l'entreprise aux opportunités offertes par le Cloud. Lesfurets.com se concentrent sur la modernisation des actifs en découpant les applications. Compte Nickel pourra alors déployer de nouveaux services et usages qui étaient difficiles à concevoir et à déployer auparavant, tels que des fonctions de temps réel dans les notifications et les traitements de données de paiements.


Dernier