Les défis de la migration des applications dans le cloud

Introduction

Si la première vague de migration cloud était orientée sur l’infrastructure à travers la virtualisation des ressources et l’automatisation des process, le développement des plateformes de services a engagé les applications dans la seconde ère de bascule dans le cloud. Cependant, une telle décision implique d’en faire une stratégie spécifique.

Comme tout projet structurant pour l’entreprise, le glissement des applications vers le cloud nécessite un important travail en amont de préparation sur différents sujets. Le premier est peut-être le plus important en s’attachant aux ressources humaines. Qui est concerné (les métiers, l’IT, les développeurs) ? Qui sont les sponsors du projet ? Y a-t-il un programme de formation prévu ? Quelle politique d’accompagnement au changement doit-on adopter ? En second lieu, il est impératif de dresser un inventaire du patrimoine applicatif ayant vocation à migrer sur le cloud public, tout en prenant en considération les conséquences financières et le choix des prestataires.

Une fois ce travail réalisé, des landing zones sont créées pour accompagner la bascule des applications sur le cloud public. Il existe alors différentes techniques pour cette migration en fonction de la typologie des applications. Si certaines ne nécessitent pas une réécriture de code, d’autres demandent un travail plus important, voir une approche opportuniste dans certains cas. Tout au long de cette démarche, les questions de sécurité et de conformité doivent être prises en compte.

1. Une phase préparatoire essentielle

La migration vers le cloud n’est plus aujourd’hui une question IT, mais bien un projet humain. Elle engendre beaucoup de changements dans les organisations et il est impératif de prendre en considération ces évolutions en amont du projet. Dans le même temps, il est nécessaire de gérer la partie opérationnelle de la migration à travers une check-list à valider.

Une conduite du changement à ne pas négliger 

La migration vers le cloud n’est plus aujourd’hui une question IT, mais bien un projet humain. Elle engendre beaucoup de changements dans les organisations et il est impératif de prendre en considération ces évolutions en amont du projet. Dans le même temps, il est nécessaire de gérer la partie opérationnelle de la migration à travers une check-list à valider.

Une check list avant migration

En parallèle de cet accompagnement au changement, les responsables du projet ont d’autres éléments à regarder avant de se lancer. Dans les priorités, la cartographie des applications est un prérequis,

 « les entreprises sont souvent surprises par la taille et la diversité de leur patrimoine applicatif »,
constate Adrien Pestel. 

L’exercice est pourtant nécessaire pour connaître les workloads et leurs dépendances avec d’autres logiciels (services partagés comme l’AD, antivirus, patch management). De plus, il permet de vérifier la documentation des applications développées et de savoir quel est le bon interlocuteur technique (développeur, administrateur de base de données, Business owner, RSSI, DSI).

En mettant en perspective le patrimoine applicatif de l’entreprise, les responsables du projet de migration peuvent déjà avoir une idée de la stratégie à adopter : choisir une bascule sur le cloud public ou rester sur on premise. 

« Dans l’arbitrage, la question des coûts arrive rapidement notamment par les coûts cachés (KVA, m² des baies, le trafic entrant et sortant, le stockage, ...), le coût des workloads en fonction du choix du cloud », analyse le CTO de Claranet. Il constate par ailleurs que « de plus en plus de projets intègrent un volet FinOps, c’est-à-dire de pilotage financier des projets cloud pour éviter les dérives de consommation ».

2. Une migration applicative en toute sécurité

Une fois cette phase de préparation réalisée, le travail n’est pas terminé. L’entreprise et les responsables IT doivent choisir les applications qui doivent migrer dans le cloud. Certaines ne posent aucun souci. Par contre, d’autres applications nécessitent plus d’attention avec des techniques de replatforming. En arrière-plan à l’ensemble de ces travaux, les questions de sécurité et de conformité de la migration se posent.

Du lift and shift au replatforming opportuniste

Il est d’usage de réaliser une landing zone en fonction du workload. Cet espace intègre les différentes caractéristiques de l’application : les dépendances, la matrice de flux, la gouvernance, la sécurité, le réseau, le modèle de delivery. Cette phase de lotissement implique d’autres préparations notamment de savoir si l’application peut être déplacée dans le cloud ou pas. La diversité en la matière est de mise face à la variété des applications.

« Certaines applications ne servent plus. Dans ce cas-là, elles sont décommissionnées » souligne Adrien Pestel. « D’autres peuvent être remplacées par des solutions en mode SaaS, mais il faut être vigilant sur les questions fonctionnelles et éviter les points de blocage », poursuit le dirigeant. Toujours dans cette liste, on trouve la méthode du « lift and shift » qui voit les applications migrer directement dans le cloud public sans nécessiter de modifications profondes du code. « Si on doit refactoriser (changement de code) l’application, on intègre des services de conteneurs pour aller vers des solutions FaaS (Function as a Service) », révèle le CTO.

Et si l’application nécessite un travail plus conséquent comme du replatforming ? Le dirigeant répond, « nous avons une approche opportuniste, cela signifie que nous cherchons de bouts de PaaS (Platform as a service) sur le cloud public (Cloud Foundry, Openshift de Red Hat) et nous remplaçons le moteur de l’application pour assurer la transition ». Cet exercice peut s’avérer payant, mais il dépend du niveau de documentation de l’application qui « varie énormément » d’un programme à l’autre.

Quid de la dette technique ? Est-elle éligible à la migration vers le cloud public ? Là encore, les solutions existent avec notamment l’hybridation. « Dans un premier temps, nous portons l’application sur notre cloud pour ensuite la basculer progressivement sur un cloud public », observe le CTO. Pour les bases de données sur des environnements de type MySQL, SQL Server ou Oracle, « « il existe deux solutions : soit déplacer dans notre cloud et basculer ensuite dans le cloud public via leurs services, soit la base de données est plus complexe et il faut alors regarder les compatibilités ». La politique des éditeurs sur le cloud public va dicter les options possibles, « il impose son rythme », reconnait Adrien Pestel, tout en défendant cette approche, « vis-à-vis de la sécurité ». 

Sécurité et conformité en toile de fond

Les aspects de sécurité guident en arrière-plan les différentes étapes et préparations citées précédemment.

 « Il faut la prendre en compte sur l’ensemble du cycle de vie du projet de migration. Si elle n’existe pas au début, elle n’existera pas à la fin », souligne le CTO de Claranet.

Les politiques de sécurité trouvent leur place naturellement dans les landing zones (règles d’accès, gestion des comptes à privilèges, règles de sécurité métiers, complémentarité avec le SOC/SIEM, prévoir des pentests, ...). Des éléments à ne pas négliger, car les récentes fuites de données ont pour origine des mauvaises configurations sur les services de stockages des cloud providers.

Certes avec le cloud public, les administrateurs systèmes découvrent les bénéfices du patch management. Plus de soucis pour les montées de version, les mises à jour de sécurité. Mais cela ne veut pas dire pour autant plus de culture de sécurité. 

« Les développeurs par exemple doivent s’orienter vers une méthode DevSecOps en intégrant la sécurité dès la conception des applications », constate Adrien Pestel.

Derrière la question de la sécurité se cache aussi la problématique de la conformité. Industries, banques, secteur public, sont soumis à des contraintes réglementaires fortes. Il est donc impératif de solliciter un partenaire de confiance disposant des certifications requises. Iso 27001, HDS, PCI DSS, sont les plus connus. Le passage à des plus hauts niveaux de certification des fournisseurs de cloud est également un gage d’expertise.