La migration cloud est toujours un sujet (y compris le retour en arrière)

Les entreprises n’ont pas achevé leur « migration vers le cloud ». Même celles s’affichant comme « cloud first » ou ayant déjà largement basculé ont en général toujours quelques serveurs ici ou là. La bascule vers le cloud, privé ou public, entraîne en effet des préoccupations techniques (tous les applicatifs ne sont pas compatibles) mais aussi financières (le coût de fonctionnement peut être supérieur) et juridiques (où sont les données sensibles ?). Plusieurs modalités sont possibles pour réaliser cette bascule. C’était le sujet de la réunion du Club de la Presse Informatique B2B du 19 avril 2023. La question juridique du cloud souverain est un sujet en lui-même et a été volontairement écartée, tout comme celle de la cybersécurité. Il s’agissait là d’examiner les modalités réelles de bascules sans se focaliser sur des sujets qui méritent des débats séparés, par exemple menés par OVH et VMware. 

Le cloud computing (traduit en Français académique par « infonuagique ») est d’une part un assemblage de technologies pré-existantes (virtualisation, orchestration, etc.), d’autre part un modèle économique lorsqu’il est sous-traité (consommation à la demande). Une entreprise peut donc opter pour un cloud privé, qu’elle possède, en choisissant de déployer les technologies du cloud dans son datacenter. Elle peut aussi recourir à des prestataires pour disposer d’un cloud privé hébergé ou de ressources d’un cloud public. Le cloud public est, par nature, un ensemble de ressources mutualisées et accessibles à la demande.

Lift & Shift : une approche toujours possible

Souvent décrié comme une solution qui ne tire pas parti du cloud mais n’en garde que les inconvénients, le Lift & Shift (emporter et déplacer) consiste à prendre son architecture antérieure et à simplement la déplacer sur des infrastructures hébergées dans un cloud, normalement public. Cette approche basique était jadis dominante. Pour Philippe Wojcik, directeur Cloud Engineering chez Oracle France, « cette approche est toujours d’actualité et peut avoir plusieurs justifications : disposer de ressources sur un temps défini, faire sortir une application vieillissante de son datacenter et préparer sa mort dans le cloud, préparer une refonte (replatforming) en cloud native… »

Cette approche est notamment choisie quand la bascule vers le cloud est impérative dans un délai court. Typiquement, quand une entreprise doit se débarrasser de son datacenter (fin d’un contrat avec un hébergeur, obsolescence technique avec fin de maintenance…), le Lift & Shift permet une migration rapide et à moindre effort. « C’est la partie la plus simple d’une bascule vers le cloud, normalement public, mais la baisse du TCO est rarement au rendez-vous » a averti Christophe Sorré, CTO Financial Services & Consumer chez IBM France. Plus sévère encore, Stéphane Berthaud, directeur Systems Engineering France & North West Africa chez Nutanix, a, lui, estimé : « la surprise sur les coût peut être importante. Le Lift & Shift n’est, techniquement, qu’un changement d’hyperviseur. » Jérôme Ternois, Sales Senior Manager chez Infor, a relevé pour sa part : « la logique d’architecture après un Lift & Shift est en fait toujours celle du on premise avec des logiciels dont il faut suivre le patching et le versionning. Rien à voir avec le SaaS et ses avantages. »

Le replatforming ou la refonte limitée

« Quand la DG impose le Move2Cloud, le DSI essaie normalement que ça coûte le moins cher possible et va plutôt opter pour le replatforming » a relevé Gabriel Ferreira, directeur technique chez Pure Storage. Avec ce type de bascule, la refonte architecturale est minimale. Certes, les applications sont juste transférées entre l’ancienne architecture et la nouvelle mais on tente de tirer parti d’une offre technique de l’hébergeur du cloud. Selon Christophe Sorré, « en fait, le replatforming est assez rare et va en général consister à utiliser la base de données proposée en PaaS au lieu de la base de données initiale. »

« Nous rencontrons du replatforming de moins en moins, c’est plutôt une étape pour aller vite avant une refonte plus approfondie » a confirmé Jérôme Ternois. Là encore, il peut y avoir de véritables (mauvaises) surprises sur les coûts, et pas seulement sur le fonctionnement quotidien, également sur la migration elle-même. C’est d’autant plus vrai que l’applicatif concerné est complexe. Christophe Sorré a rappelé : « il ne faut pas oublier qu’un ERP, notamment, a beaucoup d’intégration, de flux entrants et sortants. Une bascule peut entraîner des surprises sur ces flux qu’il faut souvent réarchitecturer ». Quand la migration concerne les communications unifiées, la complexité est aussi au rendez-vous : « il faut tout embarquer, même les liaisons opérateurs ! » a ainsi noté Bruno Husson, Vertical Account Manager chez Mitel. Cette solution voulue simple peut donc, au final, être une très mauvaise idée.

La refonte globale ou reingeneering

La « vraie » migration cloud suppose de réarchitecturer voire réécrire les applicatifs afin de tirer parti de toutes les caractéristiques du cloud. Là encore, il peut y avoir de mauvaises surprises comme l’a remarqué Stéphane Berthaud : « un développeur sur le cloud, c’est un enfant dans un magasin de jouets ! » Mais, avec un peu de rigueur, ces mauvaises surprises là peuvent être maîtrisées. Surtout, une telle approche permet de réarchitecturer en adoptant les nouvelles normes de développement. « En général, on en profite pour basculer du monolithe vers du micro-service, idéalement en recourant à des conteneurs agnostiques de l’hébergeur » a confirmé Christophe Sorré. Si l’approche par conteneurisation a des avantages indéniables, il peut cependant y avoir des limitations pour tirer partie des outils propres à tel ou tel hébergeur. Le remplacement d’un applicatif on premise par du SaaS est, quelque part, l’aboutissement de cette logique de refonte globale.

Enfin, bien entendu, selon le périmètre concerné, une entreprise peut adopter telle approche pour une partie de sa migration et telle autre pour une autre partie. Un applicatif maison sans équivalent sur le marché pourra ainsi basculer en Lift & Shift tandis qu’un logiciel de GRH standard sera remplacé par un SaaS. Une des difficultés souvent négligées est la cartographie du système d’information rarement complète. Un décommissionnement d’infrastructure peut ainsi se heurter à un logiciel qui n’était pas listé. Mais le frein le plus évident demeure celui de la souveraineté des données. Enfin, les surprises en matière de coûts peuvent entraîner des marches arrière. « Sortir du cloud public pour des raisons économiques est à la mode aux Etats-Unis actuellement » a observé Stéphane Berthaud. Pourtant, ce retour arrière n’est pas nécessairement pertinent et décidé sur des bases justes. Pour Christophe Sorré, « on compare parfois des choux et des carottes en ne prenant pas le vrai TCO du on premise et le vrai TCO du cloud. » Et puis tout changement d’infrastructure doit être correctement travaillé. « Le FinOps est un métier : une architecture mal conçue et non-optimisée entraîne des surcoûts » a asséné Philippe Wojcik.

Sur la photographie, de gauche à droite :

- Gabriel Ferreira, directeur technique chez Pure Storage ;

- Stéphane Berthaud, directeur Systems Engineering France & North West Africa chez Nutanix ;

- Jérôme Ternois, Sales Senior Manager chez Infor ;

- José Diz, animateur ;

- Christophe Sorré, CTO Financial Services & Consumer chez IBM France ;

- Philippe Wojcik, directeur Cloud Engineering chez Oracle France ;

- Bruno Husson, Vertical Account Manager chez Mitel.

Sur le même sujet

- Cloud : souveraineté et confiance ne sont pas des buzzwords !
L’hébergeur français OVHcloud et l’éditeur VMware ont pris ensemble la parole pour défendre le cloud souverain en expliquant comment garantir la confiance.