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. 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 :
- 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 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 :
- 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 plus de 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 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 :
- 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 é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 sont donc prêts à se convertir avec peu de résistance - quand les objectifs précédemment évoqués leur sont expliqués clairement - pour poursuivre 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érales d'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 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!
# Merci pour cet excellent article...
Posté par Anthony F. . Évalué à 4.
[^] # Re: Merci pour cet excellent article...
Posté par Didier DURAND (site web personnel) . Évalué à 8.
Je prépare le second volet sur le transcodage automatique. Je ferai à nouveau savoir dès que disponible.
cordialement
didier
# Des précisions
Posté par meuns . Évalué à -3.
[^] # Re: Des précisions
Posté par Earered . Évalué à 5.
Elle paye déjà le matériel IBM, qui finance le dév de Linux qui permet à IBM de réduire le coût de possession de son matériel. Ce qui rend IBM plus attractif.
[^] # Re: Des précisions
Posté par Didier DURAND (site web personnel) . Évalué à 4.
Nous ne payons plus la plate-forme mainframe hardware IBM: nous avons pu passsé sur des serveurs Intel standards vu le haut niveau de perfs de ces machines. Merci la loi de Moore!
Cordialement
didier
[^] # Re: Des précisions
Posté par IsNotGood . Évalué à 7.
Lorsque tu achetes un PC (sans OS) et installes un Linux (gratuit), tu te sens obligé obligé de donné de l'argent car tu n'es pas passé par la case taxe Microsoft ?
> mais que va faire votre entreprise pour donner le change ?
S'il n'y avait que du logiciel libre, il n'y aurait pas à "donner le change" ?
Si tu utilises du logiciel libre, tu vas investir dans le logiciel libre, tu vas payer des boites d'expertise/support de logiciel libre, tu vas avoir des employés qui bossent sur du logiciel libre, tu vas faire de la "pub" pour le logiciel libre, etc...
Économiser sur des licences de logiciel proprio, n'impose pas de donner du pognon au libre pour remercier de cette économie.
En passant, ils utilisent quoi comme distribution ?
Ils ne vont pas maintenir une distribution complète juste pour le plaisir.
[^] # Re: Des précisions
Posté par santos . Évalué à 2.
Oui.
Et pour rester sur la question de l'investissement direct auprès de la société (ou communauté) auteur de la solution logicielle, tout dépend de la valeur ajoutée que tu crée grâce à celle-ci.
Exemple 1 : je suis étudiant informaticien, je m'installe un petit serveur web chez moi pour essayer d'apprendre le PHP... manifestement, je ne crée pas de valeur ajoutée grâce à ce produit, je n'ai pas de retour sur investissement (si j'investis dedans), donc à priori, je ne me sens pas obligé de financer le projet.
Exemple 2 : je m'appelle eBay, je dégage un chiffre d'affaire annuel de quelques milliards d'euros (j'en sais rien), la quasi-totalité de mon gain provient de ma plateforme d'e-commerce, basée sur un serveur tomcat/apache (j'en sais rien non plus), là je me dois, bien évidemment, d'investir, et même à la hauteur d'une part non négligeable de mon chiffre d'affaire, dans la solution informatique libre utilisée...
voilà l'une des facettes du modèle économique du monde du libre.
Pour faire le parallèle avec le monde propriétaire et fermé, la différence est que généralement tu payes à l'achat, un prix fixe, et qui n'est pas proportionnel à la valeur ajoutée que tu génères. Bien sûr il y a des types de licences différentes, etc... mais globalement, c'est une logique assez préhistorique (comme au moyen âge, avec les écus d'or, etc...)
Justement, c'est un des graves défauts du modèle économique propriétaire.
[^] # Re: Des précisions
Posté par meuns . Évalué à 0.
Non, mais toutes les nuits je laisse la distribution que j'utilise en partage sur bit torrent, donc je participe avec mes moyens.
> S'il n'y avait que du logiciel libre, il n'y aurait pas à "donner le change" ?
Donner le change c'est un principe fondamental de la bonne entente.
> Si tu utilises du logiciel libre, tu vas investir dans le logiciel libre, tu vas payer des boites d'expertise/support de logiciel libre, tu vas avoir des employés qui bossent sur du logiciel libre, tu vas faire de la "pub" pour le logiciel libre, etc...
Justement je me demandais ce qu'ils avaient l'intention de faire. Tu cites des exemples mais ce ne sont que des exemples et pas nécessairement leurs intentions.
> Économiser sur des licences de logiciel proprio, n'impose pas de donner du pognon au libre pour remercier de cette économie.
Non, c'est sur, j'ai jamais dit le contraire et je n'ai donné aucun jugement. Par contre, je trouve dommage que cet article si bien écrit n'en parle pas.
[^] # Re: Des précisions
Posté par Didier DURAND (site web personnel) . Évalué à 3.
Nous utilisons Redhat: au début du projet, Linux devait tourner sur la plate-forme hardware mainframe. Il n'y avait alors que 2 distros possibles sur cette plate-forme: Suse et Redhat.
Maintenant que nous sommes finalement sur Intel, il y aurait plein d'autres distros possibles. Mais nous sommes restés sur Redhat
[^] # Re: Des précisions
Posté par Didier DURAND (site web personnel) . Évalué à 1.
Je ne comprends pas ce que vous voulez dire par "donner le change"? Merci de l'expliquer et j'essaierai de répondre
cordialement
didier
[^] # Re: Des précisions
Posté par meuns . Évalué à 0.
[^] # Re: Des précisions
Posté par IsNotGood . Évalué à 1.
Tu devrais poser la question différemment et/ou voir les choses sous un autre angle.
Par exemple tu aurais pu demander ce que le logiciel libre a gagné de cette migration. Si tu es préoccupé de logiciel libre, c'est une interrogation tout à fait légitime. Pas forcément un interrogation qui attend une réponse comptable ($$), mais pour comprendre comme le logiciel libre gagne à être utilisé. Par exemple via des échanges d'idées entre développeurs donc certains n'étaient pas jusqu'à maintenant famillier au libre, etc.
Avec le logiciel proprio, t'es obligé de "donner le change". T'es obligé de payer, etc... Le libre par définition tu n'es pas obligé. Donc ta question peut être choquante pour certains.
[^] # Re: Des précisions
Posté par meuns . Évalué à -1.
Sinon tu devrais peut être changer de point de vue, ce n'est pas parce tu n'est pas obligé que tu ne dois pas le faire (je te taquine :p).
Dans tout les cas, j'espère que ma question trouvera sa réponse. ;)
[^] # Re: Des précisions
Posté par IsNotGood . Évalué à 0.
Ne t'inquiète pas, j'ai "assez" contribué au libre. Et nullement sous la contrainte ou pour "donner le change" (je te taquine :p).
[^] # Re: Des précisions
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: Des précisions
Posté par IsNotGood . Évalué à 0.
Il n'y a aucun logiciel libre qui est payant.
[^] # Re: Des précisions
Posté par Didier DURAND (site web personnel) . Évalué à 3.
[De toute façon, LIbre ne veut pas dire gratuit même si c'est le cas 99.9%]
[^] # Re: Des précisions
Posté par Philip Marlowe . Évalué à 3.
# Bravo !
Posté par hentouane . Évalué à 8.
Petite question subsidiaire: l'outil de "transcodage iso-fonctionnel et automatique" Cobol/Java est-il opensource ?
[^] # Re: Bravo !
Posté par Didier DURAND (site web personnel) . Évalué à 1.
On réfléchit actuellement à ce que l'on va faire de l'outil de transcodage
cordialement
didier
[^] # Re: Bravo !
Posté par Nico C. . Évalué à 7.
Dans ces conditions, liberer cet outil serait vraiment un excellent moyen de contribuer a votre tour au Libre.
Je suis sur qu'un outil de ce genre aiderait une grande quantite de gens se posant la question de la migration de leurs vieilles applis cobol vers des technos plus modernes.
J'ai meme du mal a imaginer a quel point ca pourrait aider... je crois que si il est si bon que vous le dites (et je n'en doute pas) alors il deviendra probablement la pierre angulaire de la majorite des grosses migrations de banques, assurances, etc des prochaines annees qui commencent a serieusement eprouver le besoin d'evoluer.
De plus, votre outil a deja servi dans un projet d'une taille importante et c'est un avantage non negligeable.
Je n'ai jamais entendu parler d'outil de ce genre pour migrer du cobol vers du .net ou d'autres technos proprio... J'imagine que ca aidera les decideurs a privilegier le Libre si un outil Libre leur permettait d'automatiser une partie du processus.
Je suis assez epoustoufle du boulot que vous et votre equipe avez fait et je crois que la cerise sur le gateau pour l'ensemble de la communaute Libre serait de mettre a disposition les sources de votre transcodeur sous une licence Libre.
Quelque soit votre decision, felicitations et j'attends aussi la suite de votre recit.
# Maintenance du code Java ?
Posté par doupatex . Évalué à 5.
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 :-)
[^] # Re: Maintenance du code Java ?
Posté par BAud (site web personnel) . Évalué à 4.
oh que si /o\ ça sent le vécu
et hop la rustine qui perdure parce que "juste ça marche"
[^] # Re: Maintenance du code Java ?
Posté par doupatex . Évalué à 4.
"Ok c'est moche mais promis-juré la semaine prochaine je réécris" ... qui ne l'a pas fait un jour ;-)
Mais je pensais plutôt à du code qui est nécessaire à cause d'une limitation technique de la plate-forme d'origine. Mmmmhh un exemple un peu extrême : porter une appli utilisant des fichiers plats vers une base de données ; si on porte "tel quel" un fichier -> une table, ça risque d'être un cauchemar pour le DBA (beaucoup de redondance de données, ...).
[^] # Re: Maintenance du code Java ?
Posté par Didier DURAND (site web personnel) . Évalué à 3.
On a effectivement tout transcodé sans trop se poser ce genre de questions: le but était d'arriver vite sur la plate-forme Linux pour réduire les coûts de manière massive.
Ensuite, on peut (plus) calmement prendre le temps pour nettoyer les aberrations. Ce que l'on fait maintenant dans la joie et la bonne humeur puisque le "gros morceau" est derrière ;-)
diider
[^] # Re: Maintenance du code Java ?
Posté par Didier DURAND (site web personnel) . Évalué à 3.
Oui, il est maintenable: c'était l'un des buts fixés au transcodeur. J'y reviendrai dans le 2ème volet que je suis en train de rédiger. A suivvre donc!
Sur la stratégie (J'y reviens auss), on a décidé le contraire de vous: migrer très vite l'appli sans la rendre idéal out de suite pour arriver sur la nouvelle plate-forme (et économiser beaucoup...).
Maintenant, on peut attaquer la nouvelle génération from scratch sans trop de pression du temps par rapport aux économies d'argent car elles sont déjà faites.
cordialement
didier
[^] # Re: Maintenance du code Java ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
J'imagine que ça n'a pas du être une mince à faire que de faire ce traducteur de code...
Vivement le prochain n'épisode :-)
[^] # Re: Maintenance du code Java ?
Posté par Didier DURAND (site web personnel) . Évalué à 3.
IL y a eu pas mal de (très bon - bravo à mes collègues) boulot sur ce transcodeur. Effectivement pour les GOTO, il a fallu trouver une bonne stratégie. On en reparle au prochain épisode (que j'ai commencé à écrire plus vite que prévu, vu la demande)
cordlalement
didier
[^] # Re: Maintenance du code Java ?
Posté par zx81 . Évalué à 3.
Sans compter le bon vieux "ALTER" :
IF super_condition_à_évaluer_en_lisant_le_source ALTER LABEL445 TO GO TO LABEL978
(de mémoire...)
Imparable pour suivre le flux du code ! :-)
Mon prof d'algo nous avait dit (en 1985...): "je vois un ALTER, c'est un 0 pour la note !"
[^] # Re: Maintenance du code Java ?
Posté par IsNotGood . Évalué à 5.
On trouvera plein de goto dans le noyau linux. Ce sont des bons exemples d'utilisation de goto.
Dans un cadre pédagogique, il peut être normal d'interdire le goto car il est souvent utilisé comme une solution de facilité pour ne pas se prendre la tête à structurer son programme.
# Ne crachons pas sur les ancêtres
Posté par alouali (site web personnel) . Évalué à 10.
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.
[^] # Re: Ne crachons pas sur les ancêtres
Posté par Didier DURAND (site web personnel) . Évalué à 2.
La "page sombre" n'est pas de moi. Mais, je pense que de tels termes sont parfois utiles: ils nous font réagir et poster qch. C'est le but!
Sur le fond, je partage d'une certaine manière ce que vous dites: la dernière nouveauté est parfois dangereuse et pénible pour une entreprise et les hommes qui y travaillent. Par contre, vient le moment où elle devient réellement obsolète et là il faut savoir en changer.
C'est ce que nous avons fait pour NACA: attendre le moment où le Libre était devenu mûr pour l'entreprise puis foncer!
cordialement
didier
[^] # Re: Ne crachons pas sur les ancêtres
Posté par totof2000 . Évalué à 1.
En effet, le cout des licences est à prendre en compte, mais il faut aussi évaluer le cout de maintenance (mises a jour, etc ...) d'applications réparties su de nombreux serveurs. Durant ces dernières années, on a beaucoup parlé d'informatique répartie, mais beaucoup de boites reviennent en arrière et on tendance à recentraliser leur informatique.
[^] # Re: Ne crachons pas sur les ancêtres
Posté par IsNotGood . Évalué à 4.
Ça peut remplacer au moins 95 % des mainframes IBM. Il est donc temps de dire que Linux est près pour remplacer les mainframes IBM.
Quelques exemples chez Red Hat :
http://www.redhat.com/solutions/successstories/ (avec des exemples pour les banques).
Linux commence à faire un carton dans les télécommunications. Les éditeurs d'Unix ne s'y trompe pas. Sûr qu'ils ont tous un plan pour passer petit à petit à Linux et abandonner petit à petit leur Unix. Il n'y a peut-être que Solaris qui va faire le plus de résistance. Mais pour IBM et HP, l'affaire est entendue.
[^] # Re: Ne crachons pas sur les ancêtres
Posté par _linux_bsd_ . Évalué à 2.
Il y a maintenant 3 familles d'unices libres :
-OpenSolaris
-*BSD
-Linux
(donc linux est loin d'être seul même dans les unices)
[^] # Re: Ne crachons pas sur les ancêtres
Posté par IsNotGood . Évalué à 1.
Oui et il y a quelque mois je pensais que Solaris allait vite mourir (mais en plusieurs années :-)).
M'enfin, on voit plus Solaris s'alligner sur GNU/Linux que l'inverse.
[^] # Re: Ne crachons pas sur les ancêtres
Posté par _linux_bsd_ . Évalué à 1.
(pour rappel, OS et Linux sont immiscibles à cause de la GPL)
[^] # Re: Ne crachons pas sur les ancêtres
Posté par Didier DURAND (site web personnel) . Évalué à 1.
J'ai des références d'énormes applications "Industrielles" sous Linux. Et puis si vous prenez Google, Yahoo, Ebay: ils tournent tous à 100% sous Linux.
On parle de 1 million de serveurs chez Google. Pas scable Linux ? ;-)
cordialement
didier
[^] # Re: Ne crachons pas sur les ancêtres
Posté par _GuiGui2_ (site web personnel) . Évalué à 2.
C'est peut-être prévu pour les prochains épisodes, mais je serais curieux de savoir quelle configuration avait la machine de départ, et quelle configuration a (ont?) la (les) machine(s) finale(s).
[^] # Re: Ne crachons pas sur les ancêtres
Posté par Didier DURAND (site web personnel) . Évalué à 3.
Il n'y a aucun doute que des mainframes marchent parfaitement sous Linux mais nou avons fait des benchmarks comparatifs Intel / Mainframe. Résultats renversants! .... [Contactez-moi si besoin - Voi rmon blog]
C'est pour cela (rapport prix-performance) que nous avons choisi Intel. J'y reviendrai ultérieurement.
cordialement
didier
[^] # Re: Ne crachons pas sur les ancêtres
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Ne crachons pas sur les ancêtres
Posté par Didier DURAND (site web personnel) . Évalué à 6.
Nous ne travaillons pas à la même échelle que Google mais notre nouvelle architecture est devenue une architecture à croissance horizontale: nous avons éclaté des fonctions auparavant rassemblées sur le mainframe sur différentes boîtes. De plus, nous povons aussi facilement ajouter des serveurs comme notre application transactionnelle le demande.
Avant il fallait upgrader tout le mainframe ....avec des factures à 6 ou 7 chiffres!
cordialement
didier
[^] # Re: Ne crachons pas sur les ancêtres
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
C'est exact, en tant que relecteur (et correcteur), j'ai retouché l'article afin qu'il puisse prétendre à une première page. J'ai aussi ajouté le nom de l'auteur dans l'article, ce que Didier Durand ne se serait pas permis de faire.
Lorsque j'ai écrit sombre, je pensais à l'aspect propriétaire de ces systèmes et aussi qu'ils étaient ruineux et archaïques.
Un exemple de l'archaïsme de ce système : il fallait écrire un script JCL pour copier un fichier et il fallait gérer à la main la taille des fichiers.
[^] # Re: Ne crachons pas sur les ancêtres
Posté par Didier DURAND (site web personnel) . Évalué à 2.
Sur le fond vous avez 100% raison.
Je discutais récemment avec mon collègue qui exploite maintenant le système: le célèbre ABEND B37 résultant d'une mauvaise allocation manuelle de taille a disparu. C'est devenu un vieux souvenir! Résultat: moins de réveils en fanfare par ces alertes d'erreur. Il est donc heureux du libre.
Le "sombre" était donc justifié. FInalement, je le co-assume volontiers ;-)
# Economies / dépenses
Posté par Antoine . Évalué à 2.
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) ? :-)
[^] # Re: Economies / dépenses
Posté par Didier DURAND (site web personnel) . Évalué à 4.
Chacun ses convictions / religions. Pas de souci!
Pouvez-vous svp me dire le langage idéal du XXIe siècle pour une application de gestion commercial eet administrative selon vous? Je suis intéressé de votre opinion sur le sujet.
Cordialement
didier
[^] # Re: Economies / dépenses
Posté par Antoine . Évalué à 0.
Je ne sais pas s'il y a un langage idéal, mais il me semble qu'il serait intéressant de se tourner vers des langages plus expressifs comme Python, Ruby, ou pourquoi pas Javascript (non, pardon, là c'est une blague). Surtout s'il n'y a pas d'impératifs de performance de folie.
Parce que, sur de la "logique métier" (comme on dit parmi les gens qui savent se tenir à table) c'est-à-dire du code relativement haut niveau (je parle de niveau d'abstraction hein :-)), c'est dommage de se farcir une syntaxe hyper-rébarbative doublée d'une sémantique castratrice. Surtout s'il y a des milliers de modules à écrire et maintenir.
[^] # Re: Economies / dépenses
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
[^] # Re: Economies / dépenses
Posté par Antoine . Évalué à 1.
Mea culpa, je n'ai pas appris les derniers TLA à la mode. Peux-tu éclairer ma lanterne ?
[^] # Re: Economies / dépenses
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
En gros, quand on développe en PHP et que tu veux créer un client, tu te retrouves avec du code style :
getDbConnexion();
logAppel();
checkSecurity();
startTransaction();
try {
new Client(); (avec du sql en plus généralement)
} catch (execption e) {traiteexception();}
commitTransaction();
logFinAppel();
closeDbConnexion()...
(ou alors encore plus crade, tu fais des include)
EN Java, nous, on fait plutôt
Client c = new Client()
c.setNom("toto");
et voilà, c'est tout.
http://about.me/straumat
[^] # Re: Economies / dépenses
Posté par Antoine . Évalué à 3.
Client c = new Client()
c.setNom("toto");
Oui heu et alors ?
Tu peux écrire ce genre de wrapper dans beaucoup de langages (peut-être pas PHP mais ai-je mentionné PHP dans mon message ? hmm ? :-)).
On peut même imaginer un :
c = Client(nom='toto')
où le Client en question serait automatiquement sauvé en base avec récupération de l'id qui va bien etc. Avec SQLAlchemy ou l'équivalent Ruby ce genre de truc doit être assez facile à faire.
(la seule question en l'occurence est de savoir si tu veux par défaut que n'importe quel Client créé se retrouve sous la forme d'une nouvelle instance en base ; de façon assez saine SQLAlchemy considère que non, et te laisse appeler manuellement la méthode idoine pour sauver l'objet)
[^] # Re: Economies / dépenses
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Et je te signale que du coup, je vois pas en koi Java est plus verbeux, on on aurait pu faire
Client c = new Client("toto"); :)
http://about.me/straumat
[^] # Re: Economies / dépenses
Posté par briaeros007 . Évalué à 4.
le lgg top momout du XXIem ? Ben le C pardi
:P
[^] # Re: Economies / dépenses
Posté par reno . Évalué à 3.
Pour le domaine cité, Scala serait peut-être un langage intéréssant: sa syntaxe est propre, il est statiquement typé mais avec inférence de type locale, ce qui le rend presque aussi concis que Ruby ou Python (qui eux sont dynamiquement typé);
Scala est implémenté au dessus de la JVM et peut appeller les librairies Java, mais sa syntaxe est bien meilleure que celle de Java (c'était pas très dur).
Après est-il suffisamment mature? Je ne sais pas..
Il y a D aussi: un clone de C++ mais en plus propre (c'était facile) intégrant un GC optionnel, c'est un langage compilé avec de bonne performances, mais le developpement de librairie n'est pas sans poser des problemes..
[^] # Re: Economies / dépenses
Posté par Antoine . Évalué à 3.
http://boo.codehaus.org/
[^] # Re: Economies / dépenses
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Economies / dépenses
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Economies / dépenses
Posté par Antoine . Évalué à 3.
Ah s'il n'y a plus besoin de toucher au code pour assurer la "sécurité" d'une appli, alors c'est magique. Il faudra en parler aux gars d'OpenBSD.
Attends je connais la solution : on exporte tout dans des fichiers de configuration en XML, c'est ça ?
:-)
[^] # Re: Economies / dépenses
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Et par sécurité, j'aurais du dire "Authentification/authorisation".
http://about.me/straumat
[^] # Re: Economies / dépenses
Posté par Didier DURAND (site web personnel) . Évalué à 4.
Mais rappelez-vous, nous sommes partis en 2003: Python et Ruby, embryonnaires à l'époque (pas nés?)....
cordialement
didier
# Ah oui, c'est vendredi.
Posté par Obsidian . Évalué à 6.
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.
Espérons surtout que l'on ne fermera pas une "page sombre" pour en ouvrir une autre.
[^] # Re: Ah oui, c'est vendredi.
Posté par Didier DURAND (site web personnel) . Évalué à 1.
Je suis intéressé par votre proposition d'alternatives à Java/ Tomcat pour une application de gestion commerciale.
De même, quel langage de programmation préconisez vous ? je vous cite "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.
Merci d'avance de vos précisions
didier
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . Évalué à 5.
Diantre. Je ne suis pas futurologue ! Cela relève déjà de la gageure en temps normal, mais alors en informatique, ça devient de la mystification. Plus précisément, cela doit faire l'objet d'une étude appronfondie, celle-là même que vous avez dû mener. Ce que je peux proposer dans une réponse de forum tient donc du point de vue, rien de plus sérieux.
En fait, je n'ai rien proposé. J'écris des logiciels pour le domaine de la recherche, donc nos besoins sont assez différents de celle de la gestion d'entreprise.
Comme je l'ai dit, le monde Java est extrêmement prisé des entreprises car presque toutes les technologies modernes y sont représentées et qu'il est plus facile d'y trouver des développeurs que dans d'autres environnements. Maintenant, cela restera toujours "une machine dans une machine" et cela pose problème. C'est lent et lourd, les JVM ne sont pas déployées par défaut sur les ordinateurs du grand public ni sous Windows, ni sous Linux, la communication avec l'environnement existe mais l'intégration beaucoup moins et surtout le déploiement en entreprise d'un truc style J2EE est tentaculaire !
C'est une centrale nucléaire et le problème est le même pour toutes les technos un tant soit peu ambitieuses : c'est très efficace tant qu'il y a des gens compétents et motivés pour le faire, après cela pose problème. Le passage à l'an 2000 a conduit les grandes compagnies à rappeler les cobolistes retraités pour une revue de code. Est-ce que les systèmes complexes actuels seront stables pendant 20 ans, et est-ce qu'au bout de cette période, il sera aisé de s'y replonger pour en préparer la migration, comme vous l'avez fait aujourd'hui ?
Coté utilisateur, je préconise -dans l'absolu- quelque chose qui soit stable, rapide, et peu gourmand en ressources système et en espace disque. Evidemment, ça demande de briser beaucoup de couches d'abstraction bâties au fil du temps et, parfois, de contourner le modèle objet. Ca demande beaucoup de compétences, du temps, et ce n'est plus économiquement intéressant. N'empêche que si Java est très utilisé en milieu professionnel, je n'ai encore jamais vu un logiciel grand public vendu en rayon qui soit écrit dans ce langage.
Je pense d'autre part que les applications basées sur des masques de saisie et des adresses de page peuvent être presque directement transcrites, pour ce qui est de l'interface utilisateur, vers du web/css sans technologie associée coté client (même pas du Javascript). Cela a l'avantage de fonctionner partout sans déploiement particulier (le navigateur web, lui, est désormais présent partout). Par contre, faire une migration pour conserver le même mode opérationnel, ce n'est pas forcément intéressant.
Personnellement, je me retrouve bien dans le C/C++, qui permettent d'écrire des applications au plus bas niveau possible et en minimisant les dépendances à des ressources externes.
A titre indicatif, j'ai réalisé une grosse application CGI standalone en C++ uniquement. Il est clair que cela a de quoi faire bondir la majorité des webmestres qui me lisent et que c'est généralement inadapté pour la plupart des solutions développées sur le web. Il n'en reste pas moins qu'aujourd'hui, le déploiement de cette application de 35000 lignes, c'est un seul fichier binaire. En pesant le pour et le contre, il était plus simple pour moi de gérer mon propre système de session et de manipuler directement l'interface CGI avec des "out <<" plutôt que d'instancier un objet déjà écrit et d'appeler une méthode du sixième niveau en ayant bien pris soin de ne rien avoir émis avant, comme en PHP par exemple. Point de vue empreinte en mémoire et temps d'exécution, l'application est imbattable.
A voir au cas par cas, donc.
[^] # Re: Ah oui, c'est vendredi.
Posté par domak . Évalué à 2.
Houlaaaa...le petit joueur! T'aurais aussi pu ré-écrire le serveur http!
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . Évalué à 2.
Le truc, c'est que c'est tellement courant qu'en principe, quand on en arrive là, on utilise la première technologie web venue. En l'occurence, c'était moins lourd de réécrire le peu dont j'avais besoin plutôt que d'assimiler et d'inclure dans le projet un module dédié.
[^] # Re: Ah oui, c'est vendredi.
Posté par Didier DURAND (site web personnel) . Évalué à 2.
3 points:
1)Le problème de l'obsolesence des technologies se posera toujours
2) nous avons transcrit les écrans en dialogue HTML/CSS.
3) les programmeurs C/C++ se font encore plus rares (à mon regret: cela était mon langage initial) ) de nos jours que les progs Java. En tout cas dans l'industrie.
didier
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . Évalué à 2.
[^] # Re: Ah oui, c'est vendredi.
Posté par BAud (site web personnel) . Évalué à 2.
merci merci de me prêter tant de réflexion derrière ce fourbe lien (limite vil tiens :D) vu que c'est moi qui l'ai ajouté à la relecture. En fait j'ai hésité sur l'accent et, dans la foulée de la wikipédification dont je suis adepte, je me suis permis de l'ajouter. Il_n'y_a_pas_de_cabale c'est Vendredi ;-)
[^] # Re: Ah oui, c'est vendredi.
Posté par BAud (site web personnel) . Évalué à 4.
Il y avait pas mal de terminaux en:Wyse en utilisation aussi (dans les banques et autres...).
En 1995 (une dizaine d'années quoi), j'ai aussi vu encore pas mal de HP_3000 utilisés pour les opérations de gestion de paie par exemple, mais là c'était un peu le déclin àmha.
Question de point de vue et de vécu sans doute ;-)
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . Évalué à 3.
Il n'empêche que je ne placerai pas l'âge de gloire des mainframes à la fin des années 80. A cette époque, les terminaux proprios commençaient réellement à disparaître au profit des ordinateurs de bureaux et, parallèlement, le grand public avait déjà commencé (depuis le début des mêmes années 80) à goûter à la micro-informatique personnelle.
Je ne vois pas où il y a réécriture de l'histoire là-dedans.
[^] # Re: Ah oui, c'est vendredi.
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: Ah oui, c'est vendredi.
Posté par Didier DURAND (site web personnel) . Évalué à -2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.