Migrer vers le cloud, ce n’est pas déménager les serveurs

«Move to cloud», dans beaucoup d’entreprises, se traduit par l’une de ces deux choses: tout remettre en infrastructure as a service, machine virtuelle pour machine virtuelle, ou tout conteneuriser dans l’état, avec des images Docker de plusieurs gigaoctets qui embarquent l’application, ses dépendances et une bonne partie du système qui la faisait tourner avant.

Dans les deux cas, on a déménagé. On n’a pas migré

Le déménagement a un coût, et il est plus élevé qu’on ne le croit. Une machine virtuelle qui tourne en permanence chez un fournisseur de cloud coûte plus cher que la même dans un centre de données déjà amorti. Une image de quatre gigaoctets se construit lentement, se déploie lentement, se scanne mal et démarre trop tard pour profiter de l’élasticité qu’on était venu chercher. Et l’exploitation n’a pas changé: les mêmes personnes surveillent les mêmes machines, avec une facture en plus.

Migrer, c’est autre chose. C’est se demander, service par service, ce qui mérite encore d’exister sous forme de serveur: une base de données managée remplace une machine à administrer; une file de messages managée remplace un cluster à maintenir; une fonction ou un conteneur minimal, qui démarre en une seconde, remplace une image qui embarque un système entier. C’est réduire la surface qu’on exploite soi-même, pas la déplacer.

Cela demande de toucher à l’application, et c’est précisément ce que le déménagement voulait éviter. Mais c’est là que sont les gains: dans l’élasticité, dans l’exploitation déléguée, dans les coûts qui suivent l’usage. Un cloud rempli de serveurs portés tels quels n’offre rien de tout cela. Il offre le même système, ailleurs, plus cher.

La bonne question avant une migration n’est donc pas «comment porter tout cela?» mais «qu’est-ce que nous n’avons plus besoin de porter?»