Modernisation du mainframe : Modèles de découplage pour la migration du code d'application

Krithika Palani Selvam et Kevin Yung, Amazon Web Services (AWS)

Avril 2021(historique du document)

De nombreuses entreprises déplacent leurs charges de travail mainframe vers le cloud pour tirer parti de facteurs tels que la réduction des coûts, l'agilité accrue, la déduction des dettes techniques, le soutien à la stratégie numérique, le manque de compétences héritées des mainframes et l'analyse des données. Les charges de travail mainframe sont plus difficiles à migrer que les charges de travail x86, car les applications mainframe existantes sont souvent développées et déployées de manière étroitement couplée. Par exemple, une application mainframe peut inclure des programmes utilisés par plusieurs sous-systèmes ou directement appelés par d'autres applications. Dans ces cas, les modifications apportées aux programmes sous-jacents affectent également les sous-systèmes et les applications associés.

Pour les applications existantes, Amazon Web Services (AWS) recommande une approche progressive, dans laquelle la migration est planifiée par vagues, comme meilleure pratique. Cette approche permet de réduire les risques, car vous sélectionnez et hiérarchisez les applications étroitement liées à migrer ensemble. Cependant, cette approche n'est parfois pas aussi simple pour les migrations de mainframe que pour les migrations basées sur x86, en particulier parce que le code de l'application mainframe peut être couplé temporellement (invoqué de manière synchrone) ou couplé au déploiement (à l'aide de modules liés). La migration du code d'application couplé affecte les applications dépendantes et comporte donc certains risques. Pour réduire ces risques, vous pouvez découpler le code de l'application mainframe sans affecter les applications dépendantes. Ce guide explique certains des modèles couramment utilisés pour découpler le code d'une application mainframe à des fins de migration.

Le guide s'adresse aux responsables informatiques et commerciaux, aux architectes et analystes commerciaux, aux responsables de la migration et aux responsables techniques, aux équipes de développement, aux responsables de programmes et de projets, aux propriétaires de produits et aux responsables des opérations et de l'infrastructure qui envisagent de migrer et de moderniser leurs applications mainframe dansAWSCloud.

Résultats commerciaux ciblés

Ce guide aborde les problèmes courants auxquels vous pouvez être confronté lorsque vous migrez des programmes couplés depuis des ordinateurs centraux versAWS. Il présente des modèles de découplage de code quiAWSLes consultants en services professionnels rencontrent fréquemment dans le cadre de leurs engagements avecAWSclients. Lorsque vous utilisez ces modèles, vos applications migrées et héritées peuvent continuer à fonctionner pendant le processus de migration.

Définitions

Dans ce guide :

• UNapplication mainframefait référence à un ensemble de programmes et de sous-programmes centraux connexes qui exécutent et facilitent un ensemble de processus métier. Les applications mainframe peuvent être des systèmes de traitement par lots ou des systèmes de traitement de transaction en ligne (OLTP).

• UNcomposant mainframefait référence à un groupe de programmes et de sous-programmes dotés de fonctionnalités spécifiques.

• UNprogramme mainframefait référence à un ensemble de déclarations qui mettent en œuvre la logique métier. Les programmes peuvent être exécutés indépendamment.

• UNsous-programmeest généralement écrit pour gérer une opération réutilisable ou une logique métier requise par plusieurs applications. Un programme appelle ses sous-programmes de manière statique ou dynamique.

• UNdomaine d'activitéfait référence à une sphère spécifique qui représente une unité commerciale autonome modélisée lors de l'analyse. Par exemple, le domaine commercial d'un logiciel fait référence au domaine auquel l'utilisateur applique ce programme.

Hypothèses

Les exemples et les diagrammes de ce guide reflètent les hypothèses suivantes :

• L'application mainframe en cours de migration peut exécuter un seul programme ou plusieurs programmes. Pour des raisons de simplicité, les diagrammes de ce guide présentent deux programmes et un seul sous-programme pour chaque application.

• Les programmes et sous-programmes du mainframe sont écrits en COBOL, et le code est migré vers Java surAWS. Toutefois, vous pouvez utiliser ces modèles de découplage avec les langages de programmation de votre choix.

• Le schéma de migration estrefactorisation automatisée héritée, où le code, les données et les dépendances sont automatiquement convertis dans un langage, un magasin de données et une structure modernes, tout en garantissant l'équivalence fonctionnelle avec les mêmes fonctions métier. La refactorisation implique l'utilisation d'outils automatisés pour convertir le langage de programmation de l'ordinateur central (tel que COBOL) en langages de programmation modernes (tels que Java ou .NET).

• Les applications refactorisées sont déployées sur des conteneurs provisionnés et gérés parAWS Fargate. Fargate est un moteur de calcul sans serveur pour les conteneurs qui fonctionne avec les deuxAmazon Elastic Container Service (Amazon ECS)etAmazon Elastic Kubernetes Service (Amazon EKS). Fargate facilite la mise en service et la gestion des serveurs pour faciliter la mise en service et la gestion des serveurs.

• Les tables de base de données et les fichiers du mainframe sont migrés avec l'application.

Scénarios de migration de

Les deux principaux types d'applications mainframe existantes, du point de vue de la migration du code, sont les suivants :

• Applications autonomes

• Applications qui partagent des programmes avec d'autres applications

Les sections suivantes décrivent comment gérer les modèles de découplage pour ces deux hypothétiques hypothétiques.