Now Reading
Quatre pièges à éviter lors de la migration dans le cloud
0

Quatre pièges à éviter lors de la migration dans le cloud

by Cloud Guru25 juillet 2014

Certaines organisations continuent d’utiliser de très anciennes applications. En fait, il m’est récemment arrivé de tomber sur certaines applications dont les origines remontent au milieu des années 90 ! Des applications aussi anciennes peuvent présenter des défis assez uniques bien que ce ne soit pas flagrant au premier coup d’oeil. Mais, comme pour les personnes, elles ont encore de la valeur même si elles ont atteint un âge avancé, alors il convient de qualifier ces applications de « matures » plutôt que de vieilles.

Au cours des quelques années écoulées, j’ai travaillé avec plusieurs organisations pour les aider à migrer leurs applications matures dans le cloud. Au fil du temps, j’ai dû faire face à un bon nombre de situations difficiles et inhabituelles. Je voulais, dans cet article, mettre l’accent sur quatre des pièges que j’ai dû déjouer afin de vous aider à les éviter lors de vos projets de migration.

1.     Compatibilité des systèmes d’exploitation

Lprobleme‘un des premiers points à prendre en considération lors de la migration d’applications matures est la question du système d’exploitation sous lequel s’exécute actuellement l’application et, notamment, de la version de ce système d’exploitation.

La plupart des fournisseurs d’infrastructure sous forme de services (IaaS) vous autoriseront uniquement à créer des machines virtuelles (VM) à l’aide de systèmes d’exploitation assez récents. Si votre application s’exécute sous un système d’exploitation antérieur, ne partez pas du principe que celui-ci sera disponible auprès du fournisseur d’IaaS. En fait, vous risquez d’être bien en peine de trouver un fournisseur qui vous laissera créer des machines virtuelles avec un système d’exploitation antérieur tel que Windows 2003 Server ou Windows XP.

Si vous êtes ensuite forcé de faire passer votre application mature à une version ultérieure d’un système d’exploitation, ne partez pas non plus du principe que l’application continuera de fonctionner à l’identique sur une version ultérieure du système d’exploitation. Vous devez soigneusement tester l’application mature sous le nouveau système d’exploitation afin de vous assurer qu’elle fonctionne toujours comme prévu.

2. Disponibilité logicielle

Si vous tentez de passer un logiciel tiers mature dans le cloud, alors vous devez vous assurer que le logiciel est disponible pour le réinstaller – que le logiciel d’installation est disponible et stocké quelque part, ou que le logiciel d’installation pour cette version peut encore être téléchargé depuis le site du développeur du logiciel.

Un client avec lequel j’ai travaillé ne parvenait pas à mettre la main sur le CD d’installation de son système d’archivage et, parce que ce système était très ancien, le fournisseur ne vendait plus de copies de cette version. Ce client a alors été obligé de choisir entre payer pour une mise à niveau du logiciel vers la dernière version, et conserver le système sur site plutôt que de le passer dans le cloud.

3.     Activation des licences

Les licences des applications matures peuvent poser problème dans au moins deux cas de figure.

En premier lieu, les licences peuvent ne pas être valables pour des machines virtuelles basées cloud. Bon nombre de fournisseurs de logiciels utilisent un mécanisme d’octroi de licence qui utilise certains aspects du matériel physique, tels que les informations de carte réseau, par exemple, pour générer une licence unique liée à un ordinateur particulier. J’ai vu des cas où, avec certains fournisseurs cloud, la signature matérielle changeait à chaque démarrage d’une machine virtuelle ou chaque fois qu’une nouvelle instance était générée. Dans ces cas, le système d’octroi de licence du logiciel considère qu’il ne s’agit pas d’une installation valide, et l’application ne démarre pas.

Autre problème lié à l’octroi de licence : si vous réinstallez une application mature et devez faire une demande pour une nouvelle licence ou un code d’activation auprès du fournisseur, vous devez vous assurer que les fournisseurs émettent toujours de nouveaux codes pour cette version. Si vous possédez des logiciels qui ont bien plus que quelques années, vous devrez contacter les fournisseurs afin de vous assurer qu’ils peuvent vous fournir de nouveaux codes.

4.     Problèmes liés aux bases de données de serveur

Autre point essentiel à prendre en considération lors de la migration d’applications matures : la migration de bases de données basées serveur telles les bases de données de serveur SQL.

Vous devez d’abord vérifier les trois problèmes décrits précédemment. Ensuite, vous devrez vérifier que, si vous changez le type ou la version de la base de données, votre application continue à fonctionner. Le changement de version d’une même application de serveur de base de données est moins risqué mais nécessite néanmoins des tests de vérification.

Dernière chose à garder à l’esprit : les restrictions liées aux tailles de zone. Il ne s’agit pas d’un problème lié au serveur de base de données-même, mais vous risquez de rencontrer certains problèmes liés aux limites de taille de zone imposées par le schéma de l’application. J’ai rencontré ce problème avec un client parce que l’application fournisseur tiers à migrer comportait une limite de zone de 20 caractères pour une zone destinée au stockage des noms d’utilisateur. Tout fonctionnait à merveille quand l’application était exécutée sur site, mais une fois dans le cloud, les noms d’utilisateur étaient basés sur un nom de domaine différent, et plus long. Noeud inextricable de cette histoire, cette zone de longueur fixe ne pouvait pas prendre en charge les noms d’utilisateur plus grand, et parce que l’application provenait d’un fournisseur externe, la taille de zone ne pouvait pas être modifiée par le client. Voilà très certainement un piège à garder en mémoire.

Quels pièges avez-vous découverts ?

Nous avons étudié quatre pièges potentiels liés à la migration d’applications matures dans le cloud

1. Compatibilité et disponibilité du système d’exploitation
2. Disponibilité du logiciel d’installation d’application
3. Création de licence et compatibilité des licences avec les machines virtuelles modernes
4. Problèmes liés aux bases de données de serveur

Cette liste peut servir de liste de contrôle utile lors de l’évaluation de la viabilité du déplacement d’une charge de travail vers le cloud. Il existe toutes sortes d’autres pièges dont il faut être conscient, et j’espère en traiter d’autres dans un prochain article.

Exprimez-vous

Qu’en est-il pour vous ? Quels problèmes ou anomalies avez-vous rencontrés lors de la migration d’applications matures vers le cloud ? Laissez un commentaire ici, ou suivez-moi sur Twitter @ThingsESaid. Je vous encourage à partager vos idées avec la communauté du cloud car nous pouvons tous apprendre les uns des autres.

Ethann Castell
Ethann possède une large expérience en matière de technologie de l’information, incluant la gestion de projet, le conseil en stratégie, l’architecture de solutions et l’ingénierie logicielle. Toujours à la pointe de l’innovation, il a fondé et dirigé deux partenaires commerciaux IBM et a réussi le lancement sur le marché de plusieurs logiciels de commerce. Qualifications d’Ethann : MBA, PMP, Scrum Master et Six Sigma Green Belt. Il est ambassadeur du cloud IBM et maîtrise plusieurs langages de programmation. Quand il n’est pas au travail, vous avez plus de chances de le rencontrer en randonnée au bout du monde ou en train de supporter son équipe locale de Rugby. Il vit à Sydney, en Australie.

{lang: 'fr'}
About The Author
Cloud Guru

Vous souhaitez réagir sur cet article ?