De la connexion de son système d’information vers le cloud au design d’applications cloud native, nombreux sont les chemins qui mènent les DSI au cloud. Parmi ceux-ci, la migration d’applications dans le cloud est souvent un bon moyen d’expérimenter le cloud et de gagner en expérience sur le sujet. Nous verrons ici en détail quelles sont les différentes stratégies de migration d’applications dans le cloud, quels sont les avantages et inconvénients de ces stratégies, et dans quel contexte elles sont le plus souvent employées.

Lift and shift

Première stratégie de migration d’applications dans le cloud, la technique dite “Lift and shift” est également la plus simple et la plus rapide. Il s’agit en effet de déplacer les machines depuis les datacenters historiques directement dans le cloud, sans opérer d’autre changement. L’avantage de cette méthode est qu’elle ne demande que peu d’efforts, puisqu’on ne modifie pas du tout l’application. Il est ainsi possible de migrer une application sans connaître son fonctionnement, sans avoir la connaissance de son processus d’installation par exemple. Dans cette stratégie, on considère le cloud comme un simple datacenter supplémentaire, pour répondre au besoin d’une migration massive d’applications, sans avoir à les modifier (projet de fermeture de datacenter, par exemple). Ce type de projet peut-être mené par des équipes purement infrastructure, sans faire intervenir les équipes métier. Cependant, le taux de réussite de ces migrations est moyen, et on ne tire pas particulièrement parti des avantages du cloud. En pratique, le lift and shift peut aussi générer des problèmes liés aux différences entre les hyperviseurs ou les configurations de base des machines. Les temps de copie étant assez long, il peut se passer plusieurs heures avant de se rendre compte de l’échec de la procédure. Enfin, s’il y a des dysfonctionnements, leur origine n’est pas toujours facile à identifier.

Replatforming

La seconde stratégie de migration d’applications dans le cloud est le replatforming. Certaines applications ne peuvent pas être migrées dans le cloud, parce qu’elles fonctionnent sur des systèmes non disponibles dans le cloud (version OS, type de serveur, etc.). Pour que l’application puisse fonctionner dans le cloud, on va donc changer sa plateforme : il n’y a aucune autre modification sur l’application que celle de sa couche OS. S’il existe plusieurs variantes de replatforming, l’opération consiste globalement à réinstaller l’application. Une application qui fonctionnait sous Solaris sera par exemple réinstallée sous Linux, puis re-configurée. Cela suppose de connaître le processus d’installation de l’application, et de s’assurer que celle-ci soit compatible avec les OS disponibles sur le cloud. Des compétences spécifiques sont nécessaires : parfois l’application a été installée il y a longtemps, et on ne dispose pas forcément de documentation. La partie OS doit être reconfigurée par des équipes d’infrastructure, et les équipes métiers interviennent également sur la partie qui les concerne. En fonction des applications, c’est un processus de migration qui est plus ou moins complexe, mais qui peut être facilité si on utilise déjà des outils d’automatisation comme Puppet, Chef ou Ansible. Avec quelques modifications mineures, il est possible d’utiliser ses recettes existantes. L’avantage de cette solution est d’utiliser des machines nativement dans le cloud : il n’y pas de risque que les machines ne démarrent pas, comme dans le cas du “lift and shift”. Ce type de migration d’applications dans le cloud, plus complexe car il demande d’aller plus haut dans les couches, est généralement mené pour des applications qui ne sont pas du tout cloud ready, comme des ERP par exemple.

Cloudification

Enfin, la dernière stratégie de migration d’applications dans le cloud est aussi la plus intéressante : le cloudification d’applications permet en effet de tirer le meilleur parti des avantages du cloud. La cloudification consiste à transformer complètement une application de façon à l’adapter aux architectures cloud. L’application est re-designée : auto-scaling, loadbalancing, auto-réparation… Une application à l’origine pensée pour un datacenter historique peut ainsi devenir “cloud ready”. C’est en contrepartie un processus beaucoup plus long que les précédents. Si une migration “lift and shift” se compte en heures (mais avec un risque d’échec), le replatforming en jours, la cloudification d’applications peut prendre plusieurs en semaines en fonction de l’application. Cependant, si on souhaite migrer de cette façon plusieurs applications du même type, une fois la première application migrée, le processus est facilité pour les suivantes.

La cloudification demande d’adapter complètement l’application aux spécificités du cloud : par exemple, il n’est pas possible de stocker des fichiers en local. Sur le cloud, l’application est auto-scalée et dans ce cas ce sont plusieurs serveurs qui assurent le service, et donc le code et la configuration de l’application doivent être modifiés en fonction. Une solution pour contourner ce problème peut être de stocker les fichiers sur S3, par exemple. De nombreuses modifications doivent ainsi être apportées à l’application pour qu’elle soit fonctionnelle sur le cloud. Ceci suppose d’avoir une bonne connaissance de l’application, pour pouvoir facilement diagnostiquer en cas de problème.

Toutes ces stratégies de migration d’applications dans le cloud, et plus particulièrement la cloudification, sont de bonnes étapes pour apprendre comment tirer parti du cloud et comprendre la transformation des applications. L’étape suivante consiste à créer des applications cloud native, où toute l’architecture de l’application est pensée pour le cloud : intégration continue, déploiement et livraison automatisés, architecture blue/green, etc. Ce sujet sera traité dans un prochain article.