Projet NACA: migration Mainframe IBM vers serveurs Intel/Linux - motivations et stratégie [1]

UPDATE 01-2012: Le projet NACA a donné naissance à Eranea, société dédiée à la migration 100% automatisée de grandes applications métier vers Java et Linux. Voir  www.eranea.com ou email à contact@eranea.com pour plus d'informations
_______________________________________________________________________
Mise à jour: le code source des outils du transcodage NACA est maintenant en Open Source. Voir http://media-tech.blogspot.com/2008/07/les-outils-du-projet-naca-de-publicitas.html.
[Introduction: cet article est le premier d'une série qui décrira le projet NACA ayant conduit au remplacement d'un mainframe IBM sous MVS/OS390 par des serveurs Intel sous Linux. Le projet a été lancé en Janvier 2003 et s'est terminé avec succès au 30 Juin 2007. Il a été réalisé volontairement de manière 100% iso-fonctionnelle (i.e. sans aucune modification pendant et par le transcodage) pour l'application et a permis la conversion automatisée de 4 millions de lignes de Cobol vers leur équivalent Java. L'économie en cash-outs - paiements externes - est de plus de 85% de leur montant annuel = initial d'environ 3 millions d'euros annuels

Articles déjà parus:

• Projet NACA [4]: exemple de programme transcodé de Cobol vers Java - plugin Eclipse
• Projet NACA [3]:présentation technique et économique globale du projet
• Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol
• Projet NACA [1]: motivations et stratégie

]

]

Tout d'abord le nom du projet:

• en français, NACA = "Nouvelle Architecture Centrale d'Applications"
• en anglais, NACA = "New Architecture for Core Applications"

Comme le titre de l'article et l'acronyme ci-dessus l'indiquent, ce projet lancé par mes soins chez mon employeur Publicitas (mère de Publiconnect) a eu pour objectif initial la conversion d'un mainframe IBM modèle G5 exploité via les logiciels standards habituels (MVS/OS390, CICS, COBOL, DB2) vers son équivalent naturel dans le monde du Logiciel Libre (Open Source):Linux, Java, Tomcat, UDB. Il s'agissait d'amener l'application commerciale maison, appelée PUB 2000 et développée à la fin des années 80, vers un environnement technologique moderne et efficace.

Nous avons lancé ce projet à mi-2002 sur le constat que l'Open Source "montait en puissance" et était utilisé sur des applications autrement plus critiques que la nôtre: de multiples exemples émergeaient déjà dans le monde des industries classiques: énergie, aéronautique, aérospatial, finance avec des noms prestigieux comme Boeing, Sony, Nasa. Toutes ces applications industrielles trouvées au travers de notre veille technologique avaient des niveaux de charge et de volume bien supérieurs aux nôtres. Notre activité est d'environ 750'000 transactions par jour effectuée par une population de 1'500 utilisateurs environ.

Par ailleurs, dans un domaine moins habituel pour Publigroupe (mon employeur), des startups (de l'époque….) comme Google nous montrait qu'elles arrivaient à délivrer sur Linux un service de qualité impeccable à des très hauts volumes de charge. Certes, à l'époque pas encore avec 1 million de serveurs pour délivrer 120 milliards de pages chaque mois mais quand même avec déjà des niveaux de charge bien supérieurs aux nôtres. Côté fiabilité, la solidité prouvée de l'Open Source est bien décrite par la célèbre Loi de Linus (Torwald, père de Linux) énoncée par Eric Raymond dans son essai "La cathédrale et le bazar" (à lire ou relire, impérativement!). Cette loi dit donc ""Étant donnés suffisamment d'observateurs, tous les bogues sautent aux yeux'' .

Les feux étaient donc au vert et nous sommes lancés, conscients que de nombreux écueils se trouvaient encore devant nous car une telle migration Mainframe MVS était pour le moins pionnière (voire inconsciente ou hérétique au gré des interlocuteurs…)

Mais, nous sommes partis dans l'exploration des possibilités technologiques pour NACA car la première motivation du projet était massive: le mainframe IBM nous coûtait en "cashouts" (sommes payées aux fournisseurs IBM et tiers) environ 3 millions d'euros par an. 80%+ de cette somme, soit pas loin de 2.5 millions d'euros partaient dans les licences de location des logiciels utilisés comme "carburant de la grosse boîte".

Le calcul financier initial était donc simple (même simpliste pour certains…) : le Logiciel Libre est gratuit. La plate-forme mainframe IBM supporte le Logiciel Libre et le remplacement intégral des logiciels propriétaires d'IBM et des tierces parties par leurs équivalents Open Source permet donc réduire les coûts annuels de 2.5 millions par euros. Si on calcule abruptement...

[Note: IBM annonçait à l'époque - preuve avec le code source à l'appui - que moins de 1% du noyau de Linux était modifié pour supporter sa plate-forme hardware mainframe de la série G.On parle donc véritablement du même logiciel Open Source que pour des serveurs Intel]

Ces économies très consistantes représentaient une motivation suffisante aux yeux des gestionnaires des finances de PubliGroupe pour lancer le projet puis le soutenir dans les moments difficiles qui ne manqueraient pas de survenir (on en reparlera dans les prochains épisodes…)

Nous sommes partis avec les objectifs et lignes directrices:

• migration douce: le "big bang" de la migration globale de l'ancien au nouveau système en une nuit a été banni d'entrée. Les uns et les autres de l'équipe connaissaient tous des projets internes ou externes ayant échoué par la volonté de passer "la grande marche" en 1 seule étape. Nous avons donc décidé de construire comme chemin de projet plutôt un long escalier doté de multiples petites marches permettant de progresser irrévocablement (mais avec retour arrière possible à chaque fois)
• transcodage iso-fonctionnel et automatique: il s'agit d'éviter le mélange des genres qui conduit le plus souvent à l'émergence de nouvelles contraintes souvent fatales. Donc, nous avons décidé de migrer les fonctions écrites en Cobol 1 pour 1 vers Java. A la sortie, le code Java fait juste la même chose que le code Cobol. Il le fait et juste pour beaucoup moins cher....
• préservation des équipes en place: les collaborateurs fidèles à l'entreprise et au système depuis 20+ ans sont les plus aptes à le faire migrer. Pour autant que l'on injecte juste le sang neuf nécessaire à l'infusion des nouvelles compétences Linux et Open Source.

Le principe de la migration douce est de construire le nouveau système non pas en parallèle (i.e séparée) du système historique mais plutôt de bâtir progressivement le nouveau système en remplaçant des parties de l'ancien et en interconnectant les nouveaux composants avec l'ancien système pour délivrer une qualité de service au moins identique (voire meilleure) en permanence aux utilisateurs sans créer de césure entre ancien système et nouveaux composants. La conséquence directe de cette stratégie est que l'on commence la migration du système par les couches basses puis que l'on remonte "la pile des niveaux logiciels" pour terminer par l'application maison.

Avantage de cette progression"bottom-up": les administrateurs du système gérant habituellement ces couches basses sont les premiers à quitter l'ancien monde vers le nouveau. Ils ont donc la possibilité de dominer les technologies (nouvelles pour eux) du monde Linux et de s'y sentir très à l'aise quelques mois plus tard quand c'est le moment pour les développeurs applicatifs d'y entrer.

Par ailleurs, le transcodage iso-fonctionnel et automatique est essentiel pour la fluidité du projet. En effet, en utilisant un outil (que nous avons fini par développer "maison" - j'y reviendrai dans un autre article) de transcodage 100% automatique, on peut continuer la maintenance applicative fonctionnelle dans l'ancienne version et faire passer "fluidement" les nouveautés dans le nouveau monde par simple transcodage.

On n'impose ainsi aucune date à la mise en service de la nouvelle version Open Source de l'application qui serait par exemple due à un respect d'une nouvelle réglementation. Dans une telle situation, un conflit entre une nouvelle technologie applicative qui ne fonctionnerait pas comme prévu et une obligation règlementaire impérative pourrait avoir des conséquences dramatiques pour le projet.

Avec le stratégie retenue pour NACA, au contraire, les développeurs font leur maintenance sur l'ancien code COBOL jusqu'au jour où la nouvelle application Java est certifiée comme valide pour la production après plusieurs semaines d'utilisation opérationnelle satisfaisante. A ce moment seulement, le Java transcodé devient le nouveau code source. Avant, il n'était qu'un langage intermédiaire de compilation. [On y reviendra dans tous les détails ultérieurement]

Enfin, nous avons décidé de préserver les équipes en place au maximum en les formant au maximum sur les technologies Open Source. Le deal est très simple:

• une telle migration ne peut se réaliser sans la participation la plus entière des équipes en place. Il y a des dizaines de milliers de détails à connaître et à traiter de manière anticipée pour éviter au maximum tous les écueils (fatals) pouvant tuer le projet. Lancer les "jeunes loups de l'Open Source" contre les "vieux crocodiles du mainframe" serait la pire des erreurs de conduite d'un tel projet
• la plupart des membres des équipes (système et développement) en place souhaitent faire évoluer dans leur expertise quand il voit que le monde change autour d'eux. Ils suivent aussi l'émergence de l'Open Source depuis leur cockpit du mainframe et donc sont prêts à se convertir avec peu de résistance - quand les objectifs précédemment évoqués leur sont expliqués clairement - pour poursuivre leur carrière en tant qu'experts du monde Linux dès qu'on leur offre le service de formation nécessaire. Les experts technologiques pointus aiment le rester et savent faire ce qu'il faut en termes de "bits and bytes" pour adapter leurs connaissances généralesd'architecture informatique à une "nouvelle quincaillerie" qui fonctionnent le plus souvent sur les mêmes grands principes que la précédente génération (juste une syntaxe de commande un peu différente...)

Pour terminer ce premier épisode, j'attirerai l'attention sur le fait qu'une telle migration de l'application maison d'un contexte propriétaire fermé à un contexte Open Source ouvert apporte aussi un avantage intangible (i.e. pas quantifiable en euros) lorsque l'on démarre: celui de replacer l'application sur une plate-forme à partir de laquelle les mécanismes d'interaction avec le reste du monde (i.e. autres applications de la société) deviennent 10 / 100 /1'000 fois plus simples.

On peut donc intégrer cette application d'une manière beaucoup plus efficace et rapide: des processus "historiques" semi-automatisés et peu rapides de transfert de données d'un système à l'autre (les célèbres "moulinettes" d'import-export inter-systèmes) peuvent être remplacées par des communications directes en temps réel (type RPC - Remote Procedure Call) entre les blocs du système informatique global (par exemple entre l'application commercial et le système CRM)

En conclusion, le catalyseur initial d'un tel projet est sûrement le montant consistant des économies réalisées mais le vrai bénéfice à long terme est de replacer le système de l'entreprise dans un contexte technologique moderne qui lui permet d'améliorer son business parfois de manières imprévues au début du projet mais très significatives. Et tout cela, pendant toute la durée du projet (4.5 ans pour nous) sans jamais perturber l'évolution de l'application via la magie du transcodage automatique....

Exemples de tout ceci dans les futurs billets. Donc, à suivre!

Source: blog Media & Tech (par didier durand)