À un moment donné, nous avons tous entendu la phrase : « Mon application ne peut pas être déplacée vers le cloud… elle est basée sur AIX ou IBM i. » Ces mots viennent souvent de propriétaires d’applications qui ne souhaitent pas reconcevoir leur application pour utiliser des services natifs du cloud ; ils préfèrent de loin faire un lift-and-shift classique pour déplacer leur application sans aucun changement de code. Alors que certains prétendent qu’il s’agit d’une méthode anti-cloud pour effectuer un lift-and-shift direct sans utiliser les services natifs du cloud, il existe des cas où la migration vers le cloud sans modifier l’infrastructure d’application est logique. Ceux-ci inclus:
- Développement: Si l’entreprise se développe, il est possible qu’elle ait besoin de plus d’espace sandbox pour les développeurs ; plutôt que d’étendre les ressources sur site, ils peuvent tirer parti du cloud à la place.
- Reprise après sinistre: Exécutez les systèmes de reprise après sinistre dans le cloud au lieu d’avoir un autre centre de données financé par le client physiquement séparé pour héberger une architecture de reprise après sinistre. Le système de reprise après sinistre doit « avoir l’air et fonctionner » de la même manière que le système sur site pour que cela fonctionne efficacement.
- Test: En raison de nouvelles initiatives ou même d’anciens problèmes de qualité, il est nécessaire de disposer de systèmes de test supplémentaires qui agissent comme la production. Au lieu d’élargir les ressources sur site, les développeurs se tournent vers le cloud, mais ils ont besoin de « Test » pour ressembler à « Prod » sur site.
Étant donné qu’IBM i (AS/400) et AIX sont basés sur PowerPC et non sur x86, la route vers AWS, Azure ou Google Cloud n’est pas évidente pour ce type d’applications. Ils sont « obstinés par les nuages ».
Que se passe-t-il si la direction ou l’équipe informatique dans son ensemble souhaite réduire les coûts en déplaçant les ressources à l’extérieur du centre de données ? Peut-être qu’un bail de centre de données arrive à expiration et que l’équipe doit décider si elle souhaite renouveler ou trouver un autre moyen d’héberger les applications critiques. Si les applications principales sont basées sur IBM i (AS/400) ou AIX, quelles sont les options ?
Dans la plupart des cas, la question est : « Comment puis-je déplacer mon application « quelque part » pour lui donner des fonctionnalités de type cloud sans avoir à réécrire l’application dans des services natifs du cloud ? »
Il s’avère qu’il existe plusieurs options pour déplacer les applications héritées d’IBM i (AS/400) ou d’IBM AIX (basé sur PowerPC) vers le cloud, notamment :
- IBM Power Systems disponible sur Google Cloud
- Microsoft apporte IBM Iron à Azure pour les migrations cloud sur site
- Mettre sous tension IBM Cloud
De toute évidence, il existe des solutions pour ceux qui pensent que leur application ne peut pas fonctionner dans le cloud. En toute honnêteté, cependant, un lift-and-shift de base n’est pas exactement applicable ici. J’ai travaillé sur plusieurs projets où nous avons réussi à déplacer l’application en question vers le cloud depuis IBM i ou AIX et l’avons exécutée sans apporter de modifications à la logique de l’application. Malheureusement, le chemin pour y arriver nécessite une réingénierie car l’ensemble de l’infrastructure du centre de données n’a pas été migrée vers le cloud.
L’un de ces obstacles à la migration concerne le stockage. Sur site, il existe un réseau de stockage (SAN) où l’on peut créer des volumes de stockage affectés à des partitions logiques (LPAR) ou à des machines virtuelles. Le SAN provient d’un fournisseur spécifique, et il existe une équipe de stockage ou informatique disponible qui ne s’occupe que de ce seul composant d’architecture sur site.
Dans le cloud, les utilisateurs doivent utiliser l’architecture de stockage de leur fournisseur de cloud. Le stockage est généralement abstrait, donc on ne travaille jamais directement avec des disques durs et des baies. Les équipes informatiques construisent toujours des unités de stockage Numéros d’unité logique (LUN) attribués aux serveurs basés sur le cloud, mais cet itinéraire sera différent de celui effectué sur site. Les affectations de ressources pour le stockage et la mise en réseau fonctionneront différemment sous le capot. Mais tous les objets de stockage « invités » peuvent être appelés de la même manière qu’ils étaient sur site, de sorte que l’application s’exécutera finalement de la même manière.
Le résultat est que l’application sur site peut théoriquement s’exécuter « inchangée » dans le cloud du point de vue des fonctionnalités, mais le processus de migration nécessitera un réalignement des ressources et des techniques.
Une fois que l’application IBM i ou AIX tenace est dans le cloud, les utilisateurs peuvent lui appliquer la « flexibilité du cloud ». Par exemple, on peut « cloner » un serveur ou un ensemble de serveurs et les faire fonctionner dans un bac à sable privé. Le bac à sable ou « environnement » s’apparente à son propre centre de données virtuel et deux clones d’environnement avec les mêmes noms d’hôte, adresses IP et même adresses MAC, ne se heurtent pas car ils ne se voient pas sur le même espace réseau.
Grâce à cette flexibilité du cloud, les développeurs peuvent créer des environnements de test de production, de développement, d’assurance qualité et de résilience. Chacun fonctionne indépendamment, sans voir ni impacter le reste.
Il est désormais possible de migrer des applications « obstinées dans le cloud » comme IBM i (AS/400) ou AIX vers le cloud. Ce ne sera probablement pas la meilleure solution pour toutes les applications traditionnelles, mais j’exhorte les services informatiques à rechercher les options énumérées ci-dessus pour voir ce qui est viable pour leurs portefeuilles. Chaque acteur majeur du cloud propose une voie pour IBM i et AIX ; l’impossible est désormais possible.