jeudi 18 mars
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux

Posté par Didier DURAND (page perso, ). Modéré le 04 octobre 2007.
5
Il y a une vingtaine d'année IBM était au faîte de sa puissance et dominait outrageusement le monde de l'informatique avec ses "mainframes". Sortir du moule propriétaire OS390/MVS/CICS/COBOL/DB2 est loin d'être simple et de nombreuses entreprises ont toujours ce problème à résoudre.
C'est ainsi que le projet NACA a été lancé, il y a 4 ans. C'est un projet de migration d'une application maison de 4 millions de lignes écrites en Cobol sur mainframe IBM vers Linux, Apache Tomcat et Java.

Ce projet est maintenant terminé avec succès : 3 millions d'euros de dépenses sont ainsi économisés chaque année .

Une série d'articles sur le blog de Didier DURAND relate cette aventure. Le premier est déjà en ligne. Gageons que cet article sera le guide de ce qu'il faut faire pour fermer cette (sombre) page de l'informatique.

> Lire la suite (72 commentaires, moyenne: 2,7).   [dépêche : 11338 caractères]

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

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.

Tout d'abord le nom du projet :
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 naturels 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ées par une population de 1500 utilisateurs environ.

Par ailleurs, dans un domaine moins habituel pour Publigroupe (mon employeur), des startups (de l'époque….) comme Google nous montraient qu'elles arrivaient à fournir 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 fournir 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 (Torvalds, 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 conséquentes représentaient une motivation suffisante pour les 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 :
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 de 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 aurait pu avoir des conséquences dramatiques pour le projet.

Avec la 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 :
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 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 conséquent 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ère imprévue au début du projet - mais très significative. 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!

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Merci pour cet excellent article...

Posté par Anthony F. () le 04/10/2007 à 18:26. (lien). Évalué à 4.

... et comme après un épisode de série TV à la mode : vivement la suite !

[+] Des précisions

Posté par meuns () le 04/10/2007 à 18:48. (lien). Évalué à -3.

Vous détaillez la réussite économique et technique découlant de l'utilisation des logiciels open sources par votre entreprise, mais que va faire votre entreprise pour donner le change ?

Bravo !

Posté par hentouane () le 04/10/2007 à 19:44. (lien). Évalué à 8.

Félicitations pour ce travail titanesque.

Petite question subsidiaire: l'outil de "transcodage iso-fonctionnel et automatique" Cobol/Java est-il opensource ?

Maintenance du code Java ?

Posté par doupatex () le 04/10/2007 à 21:50. (lien). Évalué à 5.

Si j'ai bien compris, le code Java est écrit par un "traducteur" Cobol vers Java. Le code généré est-il facilement maintenable ? La qualité de l'outil de traduction doit être fondamentale dans un projet comme celui-ci ; personnellement je pense que c'est un gros risque à prendre... Et puis, le Java et le COBOL sont assez différents pour qu'un bon algorithme COBOL soit parfois un mauvais algorithme Java. Le travail de refactoring doit être colossal.

Je travaille aussi sur un projet de migration mainframe -> Linux + Java/JEE (en tant que simple programmeur), mais l'approche est différente (et le nombre de lignes beaucoup plus réduit).

Nous avons profité de la nécessité de faire évoluer l'application pour effectuer le changement de plate forme. Le projet a démarré il y a trois ans, et l'échéance prévue est 2010. L'application originale était découpée en modules (très) indépendants (je vous passe les détails pénibles sur la reprise de données...). Ces modules sont réécrits un par un, et on implémente des moyens de communication entre les deux mondes.

Naturellement, c'est sur ces points de communications que les grincements des rouages se font entendre... Mais ce problème existe aussi dans la migration "automatique" décrite dans l'article.

L'avantage, c'est que nous avons une application développée dès le début pour l'architecture J2EE. En portant les fonctions un pour un de COBOL vers Java, le risque est gros de porter aussi du code servant à contourner un problème technique dans l'architecture d'origine (je ne sais pas si je me fais bien comprendre là :-)

Bref, je trouve cet article très intéressant car il parle d'un problème important mais rarement abordé dans la "communauté open-source". L'accent mis sur l'importance du "facteur humain" est très bien vu (je peux le confirmer au quotidien).

J'attends la suite avec impatience :-)

Ne crachons pas sur les ancêtres

Posté par alouali (page perso, ) le 05/10/2007 à 08:04. (lien). Évalué à 10.

fermer cette (sombre) page de l'informatique.

Il ne faut pas exagérer, cette page ne fut pas si sombre.
L'avantage d'un système centralisé est qu'il est très fiable pour l'utilisateur, et très stable et pour le développeur.
Alors c'est bien beau de dire que les technologies modernes sont plus intéressantes, mais à l'époque où je développais sous Windows et Java à gérer les problèmes de mises à jour, de version, où je passais mon temps dans les MSDN et autres Knowledges bases, où je résolvais des problèmes réseaux qui venaient se rajouter par dessus, j'avais un pote qui travaillais en COBOL / DB2 : il avait l'esprit beaucoup plus serein, il ne se posait pas tous mes problèmes, une sérénité que je n'ai jamais connu en travaillant sur PC en architecture décentralisée.
Donc sous prétexte que c'est vieux, ne crachons pas trop vite sur les mérites de ces ancêtres.

Economies / dépenses

Posté par Antoine () le 05/10/2007 à 12:58. (lien). Évalué à 2.

Ce projet est maintenant terminé avec succès : 3 millions d'euros de dépenses sont ainsi économisés chaque année .

Et combien seront encore gâchés par l'utilisation d'un langage verbeux, rigide et dépassé comme Java (qui est à peu de choses près le Cobol du XXIe siècle) ? :-)

Ah oui, c'est vendredi.

Posté par Obsidian () le 05/10/2007 à 14:17. (lien). Évalué à 6.

Il y a une vingtaine d'année IBM était au faîte de sa puissance


J'aime bien ce goût raffiné pour le cynisme subtil : la liaison discrète du mot "faîte" vers le Wiktionnaire. Cela donne une idée du niveau de culture présumé que l'on attribue aux moules gallo-linuxéistes (qui, au passage, ne sauraient pas non plus se servir d'un dictionnaire).

Ensuite, il y a vingt ans, nous étions fin 1987. Ce n'était plus l'heure de gloire des mainframes mais au contraire celle de l'ascension en force des ordinateurs personnels 8 et 16 bits, avant même que, avec la chute progressive du prix du PC et l'explosion des réseaux locaux, on ne repasse justement à une architecture centralisée avec des serveurs.

Justement, ceux-ci ne remplissent plus que rarement leur rôle premier en entreprise. Si nous utilisons encore des batteries de serveurs accessibles avec des thin clients, pour la plupart des compagnies aujourd'hui, un serveur, c'est un dépôt de fichiers, généralement en SMB, sous Windows, avec une politique de licence d'accès client (CAL) aussi onéreuse que scandaleuse. Bref : les inconvénients de l'infrastructure sans les avantages (et sans le plaisir que pouvait apporter le métier à l'époque).

Sortir du moule propriétaire et mesurer une économie de 3 millions d'euros par an, c'est évidemment remarquable. Maintenant, est-ce que Tomcat-Java est un choix aussi évident qu'il en a l'air ? l'avenir nous le dira. Je ne pense pas qu'une technologie aussi lourde et aussi évolutive à la fois puisse être pérenne pendant vingt ans sans intervention. D'une manière générale, Java c'est bien, mais c'est un langage plus conçu pour les programmeurs que pour ses utilisateurs, à mon goût.

Gageons que cet article sera le guide de ce qu'il faut faire pour fermer cette (sombre) page de l'informatique.


Espérons surtout que l'on ne fermera pas une "page sombre" pour en ouvrir une autre.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.2245s (dont 0.0294 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !