TOOLinux

Le journal du Libre

Rendre les applications mainframe cloud native : plus facile que vous ne l’imaginez)

vendredi 17 avril 2020

Dans cette tribune, Mark Cresswell explique le concept « cloud native » et les raisons pour lesquelles les applications historiques n’ont pas pu normalement en bénéficier. Il partage ensuite des conseils pour permettre aux équipes de développement de rendre même ces applications traditionnelles « cloud native », afin de pouvoir tirer profit des innovations open source et modernes.

Rendre les applications mainframe cloud native (plus facile que vous ne l’imaginez)

Rendre les applications cloud native

Selon une fausse idée, pourtant très répandue, le cloud serait uniquement réservé aux nouvelles applications écrites spécifiquement pour cette architecture. En réalité, de nombreuses initiatives émergent pour transformer les applications historiques afin qu’elles puissent, elles aussi, en tirer parti. Les principaux acteurs du monde du cloud publient des composants d’infrastructure logicielle dans un modèle open source, afin de soutenir l’enthousiasme croissant du déploiement cloud.

Qu’il s’agisse d’agilité de développement accrue ou de scalabilité horizontale, de services mesh, de microservices ou de sécurité, pour tirer parti du cloud, il faut devenir « cloud native ».

Cependant, malgré toutes ces innovations, le cloud semble toujours et obstinément hors de portée des applications historiques qui s’exécutent sur les mainframes.

Le « cloud native » ne consiste pas simplement à exécuter des applications sur le cloud. La notion « cloud » dans l’expression « cloud native » n’a fondamentalement rien à voir avec l’endroit où l’application s’exécute. Le terme concerne plutôt l’architecture technique ainsi que la technologie relative au développement et au déploiement. Cette technologie a ses origines parmi les fournisseurs de cloud public, mais elle est désormais devenue commune, quelle que soit la cible de déploiement finale, interne ou externe, de l’application.

Pour qu’une application soit cloud native, elle doit exploiter ces technologies, ces modèles de développement et ces méthodologies rarement présents dans les applications monolithiques traditionnelles.

Les défis pour rendre les applications mainframe « cloud natives »

Selon l’adage, les applications historiques mainframe ne peuvent pas participer à l’évolution « cloud native » du monde de l’informatique. Une idée préconçue rarement remise en question qui s’explique par diverses raisons :

- Les applications mainframe ne s’exécuteront pas sur le matériel cloud sous-jacent, sans un refactoring important ou une recompilation intégrale. Elles sont généralement compilées dans un code machine spécifique au mainframe, et l’architecture du jeu d’instructions mainframe est profondément différente des plateformes x86, pierres angulaires de presque tous les services cloud.

- Les applications mainframe historiques reposent aussi sur des logiciels d’infrastructure et d’administration pour gérer l’activité transactionnelle et batch, l’accès aux données et de nombreuses autres fonctionnalités mainframe historiques. Comme les applications elles-mêmes, ces logiciels d’infrastructure sont également liés au matériel mainframe physique ; ils ne fonctionneront pas dans un environnement de cloud x86 traditionnel.

- Un pipeline de développement mainframe ne peut pas fournir de nombreuses fonctions de déploiement en continu sur lesquelles les applications « cloud natives » reposent. Par exemple, il est pratiquement impossible de créer les environnements de test sur les mainframes sans planification extensive. Il n’y a tout simplement pas de prise en charge pour les tests d’intégration axés sur les conteneurs et à grande échelle des applications historiques traditionnelles après chaque fusion d’une branche de code.

Le déploiement conteneurisé

Une grande partie de la technologie qui a émergé ces dernières années pour prendre en charge les applications « cloud natives » n’est tout simplement pas disponible dans l’environnement historique des mainframes. Sans la possibilité d’exécuter des composants d’application à l’aide d’un modèle de déploiement conteneurisé, de nombreuses autres exigences « cloud natives » ne sont pas réalisables.

Déplacer les applications en dehors du mainframe

Cela ressemble à un casse-tête, non ? Un miracle est-il possible pour rendre ces applications mainframe « cloud natives » ? Absolument.

Une première étape essentielle consiste à déplacer les applications en dehors de leur environnement mainframe. Grâce à des innovations récentes, les applications mainframe peuvent être migrées, sans modification ni recompilation, vers des systèmes open source conteneurisés via Docker où l’infrastructure mainframe fondamentale est reproduite fidèlement d’une façon « software-defined » dans le cloud. L’application peut donc fonctionner exactement comme elle le ferait dans son environnement d’origine, et le reste des étapes menant à la mise en œuvre « cloud native » peuvent être ainsi exécutées.

Tirer parti de l’innovation « cloud native » 

Bien sûr, le simple fait de déplacer une application mainframe historique et monolithique dans un environnement cloud n’en fait pas une application « cloud-native » canonique initialement. Un élément clé du processus de réhébergement implique le remplacement des interfaces (APIs) historiques (qui ne s’exécuteront pas sur x86 ou sur le cloud) par des interfaces basées sur des fonctions Linux standards et des composants « cloud native ». Ce modèle de mise en œuvre permet d’exploiter des composants « cloud native », tels que etcd pour aider à la sérialisation, des services de communication inter-processus comme gRPC, et de nombreux services d’instrumentation « cloud native », qui fournissent un avantage immédiat à mesure que l’application est migrée vers le cloud. Les applications mainframe peuvent ensuite s’exécuter dans des conteneurs fournissant une scalabilité horizontale et sans la nécessité de gestion directe de serveurs (mode « serverless »). Par ailleurs, elles peuvent tirer profit des capacités inhérentes de répartition de charge, de traçage / audit, et d’authentification granulaire, ainsi que des services de base de données relationnelle proposés par les fournisseurs de services cloud.

Refactoring progressif 

Parfois appelé modernisation incrémentale, le refactoring progressif est la méthode la plus efficace pour atteindre le nirvana que constitue une mise en œuvre totalement « cloud native ». Certes, on pourrait laisser ces applications migrées telles qu’elles sont juste après leur réhébergement sur le cloud, mais les plateformes « software-defined » permettent le refactoring spécifique de programmes ciblés au sein de l’application, qui peuvent en même temps continuer à dépendre des autres programmes mainframe inchangés de manière parfaitement naturelle. Une fois le replatforming terminé, ces applications peuvent s’intégrer parfaitement à un pipeline de développement moderne.

Travailler sur celles-ci ou toute autre application moderne (Java, etc.) se fait alors selon des procédures de maintenance et développement strictement identiques avec les mêmes outils (Eclipse, Git, Jenkins, etc.) : le langage de programmation constitue la seule différence.

Avec cette cohérence, c’est l’ensemble des services « cloud native » qui devient accessible. De plus, ces applications sont améliorées en bénéficiant de la même méthodologie de développement que les autres applications modernes.

Les données du « system of record » résidant sur les mainframes font partie des données les plus intrinsèquement précieuses pour l’entreprise. Réhéberger les applications mainframe historiques sur l’infrastructure cloud a de nombreux avantages.

Toutefois, souvent les entreprises ne réalisent pas que non seulement ce réhébergement est possible, mais que de plus il peut être effectué dans des architectures technologico-structurelles qui augmentent instantanément les possibilités de tirer profit des fonctionnalités « cloud native » - et cela, sans changement au code source. De plus, les applications ainsi remaniées sont désormais parfaitement positionnées pour le refactoring incrémental en vue d’une mise en œuvre « cloud native » plus canonique.

- Mark Cresswell, CEO, LzLabs.