lundi, octobre 01, 2007

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:
]

]
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)

17 commentaires:

Anonyme a dit…

Salut Didier,
Je te trouve un brin modeste... Je crois savoir que le nombre total de lignes de Cobol était de l'ordre de 5,8M... Quoiqu'on ne soit plus à quelques millions près, à ce niveau ;-)

Didier Durand a dit…

Salut Sylvain,

Je vais confirmer encore une fois( j'avais confirmé les 4 mios mais bon...)

a+
didier

Clément a dit…

Ma fois interessant tous ces details... Le projet dont tu avais commencé a me parler il y a maintenant 3 ans il me semble que nous nous sommes connus est donc désormais terminé...

Je n'avais a l'époque pas sais l'envergure de ce projet... colossale !

Anonyme a dit…

un peu hors sujet mais ca vaut le coup : vous avez vu la revanche de linux chez ruquier incroyable, ils voulaient jouer au plus malin avec Tonvoisin Debureau, l'auteur de travailler avec des cons (vu un post de lui, et ke le salut bien bas)
http://www.travailleravecdescons.com
et qui seme le vent recolte la tempete ! la reponse de tonvoisin debureau une pepite concernant windows
http://fr.youtube.com/watch?v=JMI-UxzSUec
linuxiens linuxiennes enjoy !!! linux s'invite chez france 2 je ne sais pas qui est tonvoisin, mais les autres avaient pas vu le coup venir !

Edmond a dit…

Une entrée remarquable Didier !
Et comnme le projet (introduit maintenant complètement) a été une totale réussite, je me réjouis des prochains épisodes !

Didier Durand a dit…

Salut Clément,

ravi de toujours t'avoir parmi mes lecteurs. Merci de l'intérêt!

J'espère qu'on se reverra bientôt!
didier

Didier Durand a dit…

Salut Sylvain,

Pierre a refait les comptes: il confirme les 4 millions.a+ didier

Didier Durand a dit…

Salut Edmond,

merci!

didier

Clément a dit…

Oui, je suis un peu ton blog quand j'en trouve le temps (la Terminale S me laisse un peu moins de temps).

J'ai vu que tu avais posté ton article sur DLFP ;) ! Bonne idée, c'est bien de montrer un peu au grand publique les grandes réussites du monde libre !

A toutes

Clément

Anonyme a dit…

Bonjour M.Durand,

Article très intéressant, non pas tant par la prouesse technique qu'il relate, mais surtout par les efforts titanesques qu'il a dû vous falloir pour faire accepter et avancer le projet politiquement.

Les projets que j'effectue dans le libre depuis dix ans sont trop souvent bloqués par des luttes politiques internes entre pro-libre et anti-libre sans aucun rapport avec la réussite technique des dossiers.

Quel a été votre secret pour que le projet puisse arriver jusqu'en production en contexte mainframe ?

PS: Si jamais vous recherchez des intervenants pour d'autres projets accueillis aussi objectivement, je suis très intéressé !

Bien à vous,

Pierre Brua

Didier Durand a dit…

Salut Clem,

ça cartonne DLFP! ;-)

Bonne chance pour la TS puis le bac!

a+

didier

Didier Durand a dit…

Bonjour Pierre,

Le point fort de la démarche, c'est clairement le business case initial: des millions d'euros économisée, cela attire l'attention des financiers et du plus haut management dès le début.

Ensuite, reste bien sûr toujours la dose de septicisme, incrédulité chez ceux pour qui le Libre est nouveau (.. et quelque peu inquiétant dans sa NON-structure commerciale=

C'est là que la structuration du projet entre en action: nous n'avons pas fait de big bang mais une successsion d'une multitude de petites étapes où le Libre s'est intégré avec le système Mainframe pour progressivement remplacer ses composants. Nous avons bouclé le mainframe en Juin mais nous avions déjà du Linux opérationnel depuis plus de 30 mois (nous avons commencé par remplacer l'impression).

C'est cette multitude de petites étapes sans trop de douleurs qui a convaincu progressivement les sceptiquqes d'autant que le Libre apportait à chaque fois des petits plus par rapport au composant mainframe remplacé (ex génération naturelle du pdf via Latex).

Il n'y a donc pas eu de bataille "politique" (j'ai horreur de ce mot dans ce contexte) mais des étapes pragmatiques qui ont montré la valeur technologique et financière de la migration.

La machine s'est ensuite positivement emballée d'elle-même. Plus qu'à terminer! ;-)

Pour votre proposition finale, il y a peut-être quoi de se trouver: contactez moi via le mail de la colonne de droite de ce blog.

cordialement
didier

Anonyme a dit…

Ce projet est particulièrement intéressant, mais je n'ai pas compris comment CICS était simulé sur Linux. Pour COBOL, le transcodage génère du Java, mais comment sont traités les appels CICS ?

Didier Durand a dit…

Bonjour Anonyme,

Nos transactions CICS sont devenues des servlets Tomcats.

En ce qui concerne les EXEC CICS du CObol originel, nous avons fait une bibliothèque qui permet de faire une action fonctionnellement équivalente en Java.

Par Ex:
- EXEC CICS WRITEQ devient l'écriture dans une structure de données de type file / pile en Java

- EXEC CICS SEND [MAP]devient l'envoi vers le navigateur du HTML correspondant à la map 3270 BMS initiale

etc etc.

Les autres billets à venir apporteront des précisions supplémentaires

Si cela ne suffit pas, contactez-moi par l'adresse en colonne de droite
cordialement
didier

Anonyme a dit…

Excellent article !

T.Guérin a dit…

Très intéressant.

Comment avez vous convaincu votre direction de prendre le risque de cette migration ?

Comment avez-vous migré les JCL ?

Quel retour avez-vous sur les performances batchs ?

Didier Durand a dit…

Bonjour T. Guerin,

a) Convaincre la direction --> arguments financiers (3 millions d'euros / an !) et avoir un plan de migration très progressif sans risque


b) migration des jcls -> outil de transcodage automatique JCL -> shells + Perl

c) Nous nous étions donné comme objectif pour le batch d'atteindre au moins les mêmes perfs (en termes de durée de traitement que le mainframe): nous avons fait dans notre NacaRT les optimisations qu'il fallait en plusieurs étapes pour atteindre cet objectif.

Contactez-moi si vous voulez davantage d'infos (téléphone, visite, etc...)

cordialement
didier