IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Cloud Computing Discussion :

AWS Mainframe Modernization est en disponibilité générale


Sujet :

Cloud Computing

  1. #41
    Membre actif
    Profil pro
    Développeur
    Inscrit en
    octobre 2008
    Messages
    83
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : octobre 2008
    Messages : 83
    Points : 270
    Points
    270
    Par défaut
    Citation Envoyé par TotoParis Voir le message
    Le COBOL IBM sous Z/OS reste la référence de ce langage dans le monde IT, les autres sont sans doute très bons aussi : https://www.cobol-it.com , https://www.microfocus.com/fr-fr/pro...cobol/overview , et il y a une version pour l'UNIX d'IBM, AIX : https://www.ibm.com/products/cobol-compiler-aix

    LOG4J est développé en JAVA, et les conditions de maintenance sont tout simplement honteuses, et la possibilité de détournement de son usage est tout simplement aussi une vraie honte.
    Du coup des centaines de milliers de sites peuvent être attaqués. JAVA est une vraie passoire en terme de sécurité.

    Pour revenir au COBOL, la récursivité existe, mais pas au niveau de l'ordre PERFORM mais au niveau de l'ordre CALL associé à la clause RECURSIVE dans le paragraphe PROGRAM-ID...
    Lire https://www.ibm.com/docs/en/cobol-zo...ecursive-calls.
    En informatique de gestion, je ne suis pas convaincu de l'utilité de la récursivité. Si cette possibilité est si tardive par rapport à d'autres langages déjà assez anciens, c'est sans doute pour cette raison.
    Sur ce plan la, j'ai envie de vous dire que tout les problèmes de sécurité lié au applications COBOL reste simplement a découvrir, et qu'elles sont probablement aussi scandaleuses voir pire que ce qui se trouve découvert dans tout projet informatique de taille conséquente. Et c'est certainement encore bien pire pour ce qui tourne sur des Mainframe, parce ce que si on trouve des problèmes dans les projets ouverts, c'est parce que des gens les cherche. Si personne ne peux chercher, ou ne veut chercher, bien entendu on ne trouvera rien.

    Et encore une fois, ce n'est pas parce que Log4J est écrit en Java que Log4J contient des vulnérabilités. En revanche, oui un programme écrit en C ou en C++ aura des vulnérabilité lié au langage a cause de du modèle mémoire, mais ce n'est pas le cas du Java.

    Vous parlez des conditions de maintenance de Log4J, mais je pense que vous ne vous rendez pas compte: on parle d'un projet ouvert, que tout le monde peut auditer, c'est sain d'y trouver des problèmes, ça veut dire qu'on les regles. Vous voulez vraiment comparer avec ce qui tourne sur des Mainframes? Simplement la machine requise pour faire tourner le programme (et donc investiguer de possible vulnerabilités) n'est d’après les responses que j'ai eu dans ce meme thread pas accessible ou emulable correctement.. Ça demande quand meme pas mal d'aveuglement selon moi..

  2. #42
    Membre chevronné
    Profil pro
    Inscrit en
    juin 2009
    Messages
    634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 634
    Points : 2 058
    Points
    2 058
    Par défaut
    Bien que j'ai que 32ans j'ai travaillé sur quelques problématiques lié au Cobol à savoir :
    • Voir si je peux faire tourner du COBOL de leur application avec un compilateur Open Source gratuit pour se séparé du propriétaire.
    • Etudier un outil qui propose de migrer du Cobol vers un framework Java concu par leur soins pour que les développeurs CoBOL puissent l'utiliser


    Pour le premier cas ma réponse a été que ça ne se fera pas de façon magique et que certaines instructions ne sont clairement pas prise en charge (j'avais eu la réponse en posant la question sur le forum du dit compilateur). EN bref il faudrait un certain effort et vu que ce n'était qu'un étude qu'on m'a fait faire vite je ne pouvais certainement pas m’engage sur la possibilité définitive de faire cela.

    Pour le second point :

    Je n'ai aucun doute que leur outils de migrations COBOL vers leur framework Java fonctionne cependant la façon dont est fait l'outil est désespérant :
    • Chaque classe Java est dans un classpath séparé, seul les librairies du framework et de base du JRE sont disponible
    • Si tu veux faire des appels entre différentes classes, tu dois construire des hashmap<String,Object> et appelé des procédure à la main. Ces classes doivent être spécifiquement enregistrées comme "procédure"
    • Mon impression global sur cette outil est qu'on a fait un framework qui dépouille Java (ou n'importe quel langage) de toute capacité d'être manipulé comme un langage de développement et a la place pouvoir être utiliser par des "secrétaires". Je comprend l'intérêt ne pas vouloir forcément faire monter pleinement en compétence d'ancien développeur COBOL en Java, pas besoin de connaître Java en profondeur pour faire de la base de données et des formulaires, mais je pense qu'il y avait moyen de faire mieux. Pour moi, si tu veux travailler sur ce framework, tu cherches un boulot gagne pain dont la compétence requise en tant que "développeur" est proche du zéro absolu.

  3. #43
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 876
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 876
    Points : 18 857
    Points
    18 857
    Par défaut
    Citation Envoyé par JPLAROCHE Voir le message
    ps: en entreprise je pratique le C depuis 1985 et bien-sur le C++ et sur OS400 depuis 1995 date d'arrivée du compilateur "C" et je n'ai jamais dit que les deux langages était comparable, mais juste sur le fait que leurs origines qui commencent à dater. (Cobol et C).
    le plus important c'est de savoir si le COBOL permet de créer des objets métiers comme il est possible dans un langage objet comme Java ou C++
    Je ne peux pas répondre à ce questionnement car je n'ai jamais programmé en COBOL.
    Parce que si vous devez développer un projet tout en procédural bref sans objets bonjour la maintenance du code...
    c'est là le plus important c'est de créer des objets métiers réutilisables et modulaires

  4. #44
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2015
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Services de proximité

    Informations forums :
    Inscription : octobre 2015
    Messages : 7
    Points : 25
    Points
    25
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    le plus important c'est de savoir si le COBOL permet de créer des objets métiers comme il est possible dans un langage objet comme Java ou C++
    Je ne peux pas répondre à ce questionnement car je n'ai jamais programmé en COBOL.
    Parce que si vous devez développer un projet tout en procédural bref sans objets bonjour la maintenance du code...
    c'est là le plus important c'est de créer des objets métiers réutilisables et modulaires
    Je ne comprends pas en quoi cela à une importance,
    à l'origine le cobol n'est pas orienté objet, et j'en aurais une utilité tellement minime que ça n'en vaudrais pas le coup.
    Le terme objet au sens où on l'entends deviendrais très vite abstrait dans le milieux bancaire selon moi.
    Je n'ai pas encore la "vision" pour concevoir ça, mais nous avons tellement d'équipes qui travaillent sur des sujets touchants aux mêmes "objets" mais sur des points tellement différents que j'ai peur que ça ai un coté 'objet fourre-tout'.

    Sinon oui beaucoup travaillent en procédural, mais on utilise plutôt le terme de "module métiers",
    ils permettent de rassembler des traitements pour gérer un aspect d'une application.

    Un grossier exemple:
    un métier de consultation pour l'équipe crédit permet de restituer les différentes listes de crédits avec les contrôles de données, ou la simple visualisation du détail d'un crédit.
    Donc tu te retrouve avec un découpage fonctionnel du métier d'un "objet" (constituer dans l'exemple par un ensemble d'enregistrements constituant un crédit)

    C'est un peu brouillon comme exemple, et il y a beaucoup de styles d'écritures, mais c'est une pratique qui est pas mal propre (par rapport à certaines vraiment flippantes).

  5. #45
    Rédacteur

    Avatar de autran
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2015
    Messages
    1 240
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2015
    Messages : 1 240
    Points : 7 682
    Points
    7 682
    Billets dans le blog
    55
    Par défaut
    Bonne année 2022,
    On arrive à plus de 40 réponse en réaction à cette news et j’ai peur que nous ne dérivions vers l’éternelle bataille entre les pro-Cobol contre les Pro-Java/C++.
    Ce type de confrontation ne nous mènera pas un consensus, puisque chacun défendra son pré carré.
    En revanche la problématique sous-jacente n’est que peu adressée dans ce fil. Et cette problématique ce résume de manière très pragmatique par le questionnement suivant : Comment fait une entreprise qui dispose d’un Système d’information développé en Cobol ou Fortran lorsque son sachant part à la retraite ?
    A mon sens il y a 3 options :
    • Appeler une SSII qui va lui tondre la laine sur le dos au prétexte que c’est une architecture et un langage de niche
    • Embaucher un jeune sachant (de 55 ans) à prix d’or dont l’entreprise deviendra captive et qui la placera dans 10 ans devant le même problème.
    • Migrer le SI vers un plateforme supporté par le marché
    Développeur Java
    Site Web

  6. #46
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 876
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 876
    Points : 18 857
    Points
    18 857
    Par défaut
    Citation Envoyé par chaton-garrou Voir le message
    Je ne comprends pas en quoi cela à une importance,
    Je n'ai pas encore la "vision" pour concevoir ça, mais nous avons tellement d'équipes qui travaillent sur des sujets touchants aux mêmes "objets" mais sur des points tellement différents que j'ai peur que ça ai un coté 'objet fourre-tout'.
    l'intérêt de créer des objets métiers c'est aussi de pouvoir les vendre à des autres entreprises et de gagner de l'argent c'est surtout ça qui est important

  7. #47
    Expert éminent
    Avatar de Escapetiger
    Homme Profil pro
    Administrateur système Unix - Linux
    Inscrit en
    juillet 2012
    Messages
    1 266
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Administrateur système Unix - Linux

    Informations forums :
    Inscription : juillet 2012
    Messages : 1 266
    Points : 9 496
    Points
    9 496
    Par défaut
    Citation Envoyé par autran Voir le message
    En revanche la problématique sous-jacente n’est que peu adressée dans ce fil. Et cette problématique ce résume de manière très pragmatique par le questionnement suivant : Comment fait une entreprise qui dispose d’un Système d’information développé en Cobol ou Fortran lorsque son sachant part à la retraite ?
    A mon sens il y a 3 options :
    • Appeler une SSII qui va lui tondre la laine sur le dos au prétexte que c’est une architecture et un langage de niche
    • Embaucher un jeune sachant (de 55 ans) à prix d’or dont l’entreprise deviendra captive et qui la placera dans 10 ans devant le même problème.
    • Migrer le SI vers un plateforme supporté par le marché
    Tout à fait d'accord pour la problématique, il existe normalement la GPEC (Gestion prévisionnelle des emplois et compétences) dans les grosses structures.

    Le client final (Entreprises hors SSII/ESN, Administrations) ne veut plus investir dans le legacy alors que dans d'autres secteurs où les compétences s'acquièrent sur un temps long (le nuclèaire, le pétrole, etc.), des actions de mentorat, transfert de connaissances des séniors vers les plus jeunes, ont été mises en place pour anticiper et lisser l'effet Papy-boom (désigne le grand nombre de départs à la retraite qui doivent avoir lieu entre 2006 et 2025 dans les pays développés.)

    En France, le recours à la sous-traitance, le turnover induit (perte du savoir) et le taux d'emploi faible des séniors concourrent à une situation de blocage.

    On sait qu'il faut environ 2 ans de pratique quotidienne pour maîtriser a minima un domaine, Cobol ou Java compris.

    Que voit-on sur le marché ?
    Des offres de re)conversion pour des jeunes Bac +5 scientifiques (moins de 28 ans pour la POEI - préparation opérationnelle à l’emploi individuelle - financée par l'état), comme avant l'an 2000 et le passage à l'Euro - on prend les mêmes recettes.

    Certain.e.s sont devenus d'éminents professionnels, d'autres ont quitté le navire, changé de domaine d'activité, etc.
    « Developpez.com est un groupe international de bénévoles dont la motivation est l'entraide au sens large » (incl. forums developpez.net)
    Club des professionnels en informatique

  8. #48
    Membre actif
    Profil pro
    Développeur
    Inscrit en
    octobre 2008
    Messages
    83
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : octobre 2008
    Messages : 83
    Points : 270
    Points
    270
    Par défaut
    Citation Envoyé par chaton-garrou Voir le message
    Je ne comprends pas en quoi cela à une importance,
    à l'origine le cobol n'est pas orienté objet, et j'en aurais une utilité tellement minime que ça n'en vaudrais pas le coup.
    Le terme objet au sens où on l'entends deviendrais très vite abstrait dans le milieux bancaire selon moi.
    Je n'ai pas encore la "vision" pour concevoir ça, mais nous avons tellement d'équipes qui travaillent sur des sujets touchants aux mêmes "objets" mais sur des points tellement différents que j'ai peur que ça ai un coté 'objet fourre-tout'.

    Sinon oui beaucoup travaillent en procédural, mais on utilise plutôt le terme de "module métiers",
    ils permettent de rassembler des traitements pour gérer un aspect d'une application.

    Un grossier exemple:
    un métier de consultation pour l'équipe crédit permet de restituer les différentes listes de crédits avec les contrôles de données, ou la simple visualisation du détail d'un crédit.
    Donc tu te retrouve avec un découpage fonctionnel du métier d'un "objet" (constituer dans l'exemple par un ensemble d'enregistrements constituant un crédit)

    C'est un peu brouillon comme exemple, et il y a beaucoup de styles d'écritures, mais c'est une pratique qui est pas mal propre (par rapport à certaines vraiment flippantes).
    C'est important pour éviter ce qu'on appelle les bases de code monolithique et permettre la réutilisation. Base de code monolithique qui sont, d’après ce que j'ai pu lire, particulièrement typique du COBOL.
    Mais je trouve au final que l'orienté objet pose beaucoup de problème, notamment parce qu'on fait facilement n'importe quoi avec, combien de fois par semaine je découvre des interfaces qui n'ont aucune raison d’être, simplement crée parce que "c'est comme ça que je fais d'habitude", ce qui est selon moi un scandale absolu mais bon apparament faut que je vive avec ces gens qui pense que c'est la bonne façon de faire... Sans parler des methodes faite virtuelle "ben au cas ou je voudrai la surcharger" Bref personne n'a vraiment compris comment l'OO fonctionne, et c'est tellement devenu standard que tu passe pour un pointilleux quand tu rappel qu'une interface c'est pas fait pour te rassurer en faisant croire que ca te permettra de rattraper tes erreurs de design (ou plutot l'absence de design)..

  9. #49
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    octobre 2013
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2013
    Messages : 2
    Points : 0
    Points
    0
    Par défaut Ignorance de l'ampleur du patrimoine applicatif Mainframe encore en Cobol 1 parfois. Malgré les solutions IBM
    Citation Envoyé par Bill Fassinou Voir le message
    AWS veut-il tuer les mainframes ? Le fournisseur de services de cloud computing veut remplacer les mainframes par des serveurs à grande échelle
    et COBOL par Java

    Lors de l'édition 2021 de son événement re:Invent, qui s'est tenu du 29 novembre au 3 décembre à Las Vegas au Nevada, AWS a fait une flopée d'annonces, dont une a particulièrement retenu l'attention : le leader mondial des services de cloud computing a présenté "AWS Mainframe Modernization", un nouveau service géré qui permet aux entreprises de migrer leurs charges de travail mainframe vers le cloud. Beaucoup d'acteurs ont applaudi cette annonce et des critiques ont déclaré que AWS Mainframe Modernization pourrait être la réponse au problème des migrations de mainframes ridiculement complexes.

    AWS pourrait nuire aux entreprises fournisseurs de mainframes

    Même si les mainframes sont encore très présents dans les grands groupes, en particulier dans les banques et les assurances, et continuent d'être la colonne vertébrale d'une immense quantité de transactions, ils sont désormais en voie de disparition. Et AWS semble vouloir accélérer cette tendance. En effet, aujourd'hui, le coût, l'agilité et de nombreux autres facteurs incitent les entreprises à migrer vers des infrastructures modernes, mais un certain nombre de problèmes doivent être traités avant, pendant et après le processus de migration. Il s'agit, entre autres, de la complexité des applications et de leur compatibilité avec le cadre cible proposé.


    Tous ces éléments auront une incidence sur les résultats de la migration et sur les opérations commerciales globales d'une entreprise. Comme la gestion des systèmes informatiques hérités tels que les mainframes pose un certain nombre de défis, les responsables informatiques doivent être préparés à faire face à ces problèmes et à ces processus complexes. Ainsi, bien que certaines organisations ressentent le besoin de migrer leurs charges de travail vers une infrastructure moderne, elles peinent à franchir le pas. La réponse du leader mondial des services de cloud computing est "AWS Mainframe Modernization". Le nouveau service offre deux options aux clients.

    Certains peuvent vouloir remanier leurs charges de travail mainframe pour les faire fonctionner sur AWS en transformant les applications héritées - probablement écrites en COBOL - en services modernes basés sur Java dans le cloud. Les clients peuvent également conserver leurs applications telles qu'elles sont écrites et réorganiser leurs charges de travail sur AWS en réutilisant le code existant avec un minimum de modifications. AWS Mainframe Modernization promet un pipeline de migration complet, de bout en bout, qui comprend les outils de développement, de test et de déploiement nécessaires à l'automatisation du processus.

    « Avec le lancement d'AWS Mainframe Modernization, les clients et les intégrateurs de systèmes peuvent désormais moderniser plus rapidement leurs charges de travail mainframe existantes de manière prévisible et se débarrasser d'une grande partie de la complexité et du travail manuel qu'impliquent les migrations », a déclaré William Platt, directeur général des services de migration chez AWS. Ce service met le fournisseur de services de cloud computing en concurrence avec les fabricants de mainframes et les fournisseurs de logiciels spécialisés, parmi lesquels IBM, Unisys, Bull, NEC et Fujitsu. Le nouveau produit d'AWS pourrait être un bâton dans leurs roues.

    Selon Adam Selipsky, PDG de l'entreprise, AWS Mainframe Modernization peut réduire le temps de migration de deux tiers grâce à l'automatisation quasi complète du processus. En partant d'une analyse du mainframe, AWS Mainframe Modernization décide si le "refactoring" ou le "replatforming" est la meilleure solution avant de proposer des options.

    Il peut également automatiser la réécriture du code : Selipsky a spécifiquement déclaré qu'il est capable de convertir COBOL en Java tout seul. Cette dernière fonctionnalité ne manquera pas d'enthousiasmer ceux qui veulent utiliser l'apprentissage automatique et ses capacités d'analyse, mais qui n'ont pas le bagage nécessaire pour le faire.

    Les produits d'AWS pourraient accélérer la disparition des mainframes

    Plus de 50 ans après l'apparition du premier mainframe, le System/360 d'IBM, ces machines imposantes sont encore très présentes dans les secteurs de la banque, de l'assurance et du commerce de détail, grâce à leur capacité à traiter efficacement d'énormes volumes de transactions, et à leur réputation en matière de sécurité et de temps de fonctionnement. Cependant, ces systèmes sont incroyablement coûteux et difficiles à entretenir, et le nombre de personnes qualifiées pour s'occuper de ces logiciels anciens ne cesse de diminuer. Depuis des années, AWS tente d'inciter ses clients à délaisser les mainframes et migrer vers ses centres de données.



    Cette fois-ci, l'entreprise affirme avoir construit un moteur d'exécution qui fournit toutes les capacités de calcul, de mémoire et de stockage nécessaires à l'exécution d'applications remaniées et "replatformées", tout en gérant automatiquement l'approvisionnement en capacité, la sécurité, l'équilibrage des charges, la mise à l'échelle et la surveillance de l'état des applications. AWS a assuré que comme tout cela se fait via le cloud public, il n'y a pas de coûts initiaux, et les clients ne paient que pour la quantité de calcul provisionnée.

    La banque brésilienne Banco Inter a été l'une des premières organisations à s'inscrire à Mainframe Modernization avec AWS. « En utilisant le runtime géré AWS Mainframe Modernization, nous espérons simplifier nos opérations de traitement des cartes pour une résilience et une évolutivité accrues », a déclaré Guilherme Ximenes, directeur technique chez Banco Inter. « Nous sommes également enthousiasmés par le pipeline DevOps CI/CD qui nous permettra d'accroître l'agilité dont nous avons besoin pour offrir plus rapidement à nos clients de nouvelles capacités de transaction par carte de crédit et de débit ».

    Par ailleurs, certains critiques pensent qu'AWS Mainframe Modernization est particulièrement bienvenue dans le monde post-pandémique, qui a vu les mainframes et COBOL revenir dans l'actualité en raison de l'incapacité des vieux mainframes obsolètes à traiter les demandes de chômage. « Les mainframes sont ainsi revenus dans l'esprit du public et l'on s'est rendu compte que tout le monde voulait qu'ils disparaissent, mais que la plupart d'entre eux en dépendent encore », ont-ils déclaré.

    Actuellement, AWS Mainframe Modernization est disponible en avant-première dans les régions de l'Est des États-Unis (N. Virginia), de l'Ouest des États-Unis (Oregon), de l'Asie-Pacifique (Sydney), de l'UE (Francfort) et de l'Amérique du Sud (São Paulo), avant d'être étendu à d'autres sites "dans les mois à venir".

    Source : AWS

    Et vous ?

    Quel est votre avis sur le sujet ?
    Que pensez du service géré AWS Mainframe Modernization ?
    IBM doit-il craindre pour son chiffre d'affaires sur le marché des mainframes ?
    Pensez-vous que les mainframes vont effectivement disparaître ou resteront-ils encore longtemps ? Pourquoi ?

    Voir aussi

    AWS présente une flopée de nouveaux services de bases de données et de ML, et annonce en Preview version RDS Custom pour Microsoft SQL Server et AWS DMS Fleet Advisor

    98 % des responsables informatiques envisageraient de migrer des mainframes vers le cloud, même si 96 % d'entre eux considèrent que les applications mainframe sont importantes, selon LzLabs

    AWS présente Proton, le service de gestion des conteneurs, pour automatiser le développement et le déploiement des conteneurs et d'applications "serverless"

  10. #50
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    octobre 2013
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2013
    Messages : 2
    Points : 0
    Points
    0
    Par défaut J'ai travaillé sur des chaines batch migrées du Cobol vers Java. Temps de traitement multiplié par 10.
    Citation Envoyé par walfrat Voir le message
    Bien que j'ai que 32ans j'ai travaillé sur quelques problématiques lié au Cobol à savoir :
    • Voir si je peux faire tourner du COBOL de leur application avec un compilateur Open Source gratuit pour se séparé du propriétaire.
    • Etudier un outil qui propose de migrer du Cobol vers un framework Java concu par leur soins pour que les développeurs CoBOL puissent l'utiliser


    Pour le premier cas ma réponse a été que ça ne se fera pas de façon magique et que certaines instructions ne sont clairement pas prise en charge (j'avais eu la réponse en posant la question sur le forum du dit compilateur). EN bref il faudrait un certain effort et vu que ce n'était qu'un étude qu'on m'a fait faire vite je ne pouvais certainement pas m’engage sur la possibilité définitive de faire cela.

    Pour le second point :

    Je n'ai aucun doute que leur outils de migrations COBOL vers leur framework Java fonctionne cependant la façon dont est fait l'outil est désespérant :
    • Chaque classe Java est dans un classpath séparé, seul les librairies du framework et de base du JRE sont disponible
    • Si tu veux faire des appels entre différentes classes, tu dois construire des hashmap<String,Object> et appelé des procédure à la main. Ces classes doivent être spécifiquement enregistrées comme "procédure"
    • Mon impression global sur cette outil est qu'on a fait un framework qui dépouille Java (ou n'importe quel langage) de toute capacité d'être manipulé comme un langage de développement et a la place pouvoir être utiliser par des "secrétaires". Je comprend l'intérêt ne pas vouloir forcément faire monter pleinement en compétence d'ancien développeur COBOL en Java, pas besoin de connaître Java en profondeur pour faire de la base de données et des formulaires, mais je pense qu'il y avait moyen de faire mieux. Pour moi, si tu veux travailler sur ce framework, tu cherches un boulot gagne pain dont la compétence requise en tant que "développeur" est proche du zéro absolu.

  11. #51
    Responsable Systèmes


    Homme Profil pro
    Gestion de parcs informatique
    Inscrit en
    août 2011
    Messages
    15 554
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Gestion de parcs informatique
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 15 554
    Points : 37 527
    Points
    37 527
    Par défaut
    Tout d'abord je précise que je ne connais pas du tout COBOL, mis à part son nom.

    On en retrouve dans les très grandes structures (banques, assurances, etc.) donc des très gros programmes avec des très gros traitements, et en plus critique.
    Cela représente donc beaucoup de lignes de codes à refaire, ou éventuellement à "mouliner" avec les contraintes problèmes y afférent. Le projet doit être réalisé par des personnes ayant à la foi des compétences en COBOL, et dans les technologies plus récentes remplaçantes, donc un profil assez rare.

    Cela représente donc un cout conséquent, qui n'en vaut pas forcément la chandelle, l'existant répondant au besoin et surtout testé et approuvé.

    Et pourtant, pour moi, la bascule va être inéluctable pour les raisons suivantes :
    - les anciens maitrisant COBOL partent à la retraite sans remplacement en terme de compétence COBOL
    - L'avenir n'est pas à mon avis aux mainframes, les derniers grands calculateurs étant plutôt des clusters de grosses machines standards qu'une très grosse machine spécifique. Ils ne vont pas disparaitre demain non plus, mais à terme oui.

    Que COBOL soit remplacé par Java ou un autre langage ne représente pas le fond du problème.

    Un cas de réussite de bascule a été évoqué, il aurait été intéressant d'avoir une estimation du cout, de temps passé et une volumétrie permettant d'estimer la taille du projet.

    J’ai vu un cas de migration AS400 vers SAP, qui a été abandonné, mais c'est pas la technique le problème, c'est le cout, le temps, l’implication des participants, les bonnes analyses, etc. J'en ai vu aussi qui ont réussi.

    A partir du moment ou on est sorti du mainframe, la question du cloud ou non ne se pose plus (AWS ou autre).

    Les mainframe évoluant également, je pense qu'ils ne sont pas forcément compatible avec le cloud (reste à confirmer ou infirmer, je ne fais pas de maniframe).

    Sur du moyen terme, je pense qu'on va plutôt sur du mainframe et cloud que du mainframe ou cloud.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur le P2V, mon article sur le cloud
    Consultez nos FAQ : Windows, Linux, Virtualisation

  12. #52
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    6 946
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 6 946
    Points : 158 417
    Points
    158 417
    Par défaut AWS Mainframe Modernization est disponible
    AWS Mainframe Modernization, un nouveau service géré permettant de migrer les charges de travail mainframe vers le cloud, est disponible.
    Des analystes estiment que la dette technique d'un tel déploiement pourrait vous rattraper

    Lors de l'édition 2021 de son événement re:Invent, qui s'est tenu du 29 novembre au 3 décembre à Las Vegas au Nevada, AWS a fait une flopée d'annonces, dont une a particulièrement retenu l'attention : le leader mondial des services de cloud computing a présenté AWS Mainframe Modernization, un nouveau service géré qui permet aux entreprises de migrer leurs charges de travail mainframe vers le cloud. Rendu en juin 2021, Amazon annonce sa disponibilité générale

    AWS essaie d'aider les organisations à migrer leurs charges de travail basées sur le mainframe vers le cloud et potentiellement à les transformer en services cloud natifs modernes. L'initiative Mainframe Modernization a été dévoilée lors de la conférence Re:Invent de la grande enseigne du cloud à la fin de l'année dernière, où le PDG Adam Selipsky a affirmé que « les clients essaient de quitter leurs mainframes aussi vite qu'ils le peuvent ».

    Que cela soit basé sur la réalité ou non, AWS admet qu'une telle migration impliquera inévitablement que le client passe par un processus long et complexe qui nécessite plusieurs étapes pour découvrir, évaluer, tester et exploiter les nouveaux environnements de charge de travail : « Aujourd'hui, de nombreux clients dans divers secteurs souhaitent moderniser leurs applications basées sur le mainframe pour tirer parti du cloud, mais pour ce faire, ils doivent passer par un processus long et complexe ».

    Pour y parvenir, le service Mainframe Modernization propose un environnement de développement et d'exécution complet destiné à faciliter la modernisation et l'exécution de leurs charges de travail mainframe sur AWS. Alternativement, les clients peuvent conserver les applications existantes telles quelles et les reformer sur AWS avec des modifications de code minimales, explique AWS :

    « Ce processus de modernisation des charges de travail mainframe à exécuter dans le cloud nécessite plusieurs étapes pour découvrir, évaluer, tester et exploiter les nouveaux environnements de charge de travail. Chaque étape peut être difficile et nécessite des outils personnalisés ou tiers qui doivent être calibrés pour chaque environnement client individuel, avant que les équipes de projet de modernisation puissent commencer la tâche complexe de transformer les programmes mainframe en services cloud. En raison de la complexité de la modernisation des applications mainframe, les entreprises se tournent généralement vers des consultants et des intégrateurs de systèmes (IS) pour mener des projets de modernisation mainframe. Les organisations sont également confrontées au défi de devoir configurer, exécuter et exploiter des systèmes mainframe avec les meilleures pratiques modernes de développement et de déploiement d'applications dans les nouveaux environnements cloud. Alors que de plus en plus de clients souhaitent moderniser leurs applications basées sur mainframe, ils peuvent tirer des avantages démesurés de meilleurs outils qui leur permettent d'exécuter plus facilement leurs charges de travail dans le cloud pour réaliser des coûts et une agilité améliorés ».

    Nom : aws.png
Affichages : 949
Taille : 48,1 Ko

    L'environnement d'exécution géré intégré au service Mainframe Modernization est conçu pour fournir le calcul, la mémoire et le stockage nécessaires pour exécuter des applications refactorisées et reformatées. Il automatise également le provisionnement des capacités, la sécurité, l'équilibrage de charge, la mise à l'échelle et la surveillance de l'état des applications.

    Cette fonctionnalité est apparemment alimentée par Micro Focus Enterprise Server, un environnement de déploiement d'applications existant pour l'exécution d'applications mainframe IBM sous Linux ou Windows.

    Phil Dawson, vice-président de Gartner Research, a averti que les entreprises qui migrent des charges de travail mainframe vers le cloud devront presque certainement les refactoriser ou les recoder à un moment donné dans le futur : « Un passage au cloud pour les applications COBOL peut sembler attrayant, mais la dette technique finira par vous rattraper », a-t-il déclaré.

    On ne s'attend pas à ce que les clients fassent tout le travail eux-mêmes; AWS indique qu'avec les outils de modernisation du mainframe, les intégrateurs de systèmes peuvent découvrir les charges de travail du mainframe, évaluer et analyser la préparation à la migration, puis planifier des projets de migration et de modernisation.

    L'un de ces intégrateurs est Infosys, qui a déclaré que le nouveau service lui permet d'aider les clients à obtenir les avantages du cloud tout en conservant les années de connaissances commerciales intégrées à leurs systèmes mainframe.

    « Le service de modernisation du mainframe d'AWS nous permet d'offrir ces avantages à nos clients. Il a renforcé nos capacités déjà étendues de modernisation du mainframe et nous permet de créer plus rapidement des applications numériques natives modernes, évolutives, et à moindre coût et risque », a déclaré le président d'Infosys et le PDG Eric Paternoster dans un communiqué.

    Pour le refactoring, AWS offre des capacités automatisées acquises grâce à l'achat du spécialiste de la migration Blu Age l'année dernière. Selon AWS, il peut convertir des applications écrites dans des langages tels que COBOL, PL/1, NATURAL, RPG/400 et COBOL/400 en services Java et en frameworks Web.

    « AWS Mainframe Modernization fournit un environnement de développement et d'exécution complet qui permet aux clients de moderniser et d'exécuter plus rapidement et plus facilement leurs charges de travail mainframe sur AWS. AWS Mainframe Modernization intègre les outils nécessaires pour moderniser les applications mainframe à l'aide d'un environnement unique qui crée un pipeline de modernisation de bout en bout. Avec AWS Mainframe Modernization, les clients peuvent refactoriser leurs charges de travail écrites pour les mainframes vers des services cloud modernes. Ou bien, les clients peuvent conserver les applications existantes telles qu'elles ont été écrites et les reformer sur AWS avec des modifications de code minimales. Que les clients choisissent de refactoriser ou de reformater leurs charges de travail, AWS Mainframe Modernization fournit un environnement d'exécution géré et basé sur le cloud pour les applications modernisées qui permet d'automatiser le provisionnement de capacité, la sécurité, l'équilibrage de charge, la mise à l'échelle automatique et la surveillance de la santé des applications sans infrastructure sous-jacente pour y parvenir. AWS Mainframe Modernization fournit également des capacités d'intégration continue et de livraison continue (CI/CD) pour permettre les meilleures pratiques de développement et de déploiement d'applications modernes, afin que les clients puissent exploiter leurs charges de travail modernisées en production de manière continue avec l'agilité, l'élasticité et les économies supérieures de AWS. Les clients et les SI peuvent également utiliser AWS Mainframe Modernization pour aider les équipes à mieux évaluer la modernisation des applications mainframe et réduire les risques et accélérer la modernisation des charges de travail mainframe à l'aide d'AWS ».

    « Les clients nous disent souvent qu'AWS est le meilleur endroit pour exécuter n'importe quel type d'application en raison de son étendue et de sa profondeur inégalées de services spécialement conçus. Cependant, les entreprises d'une grande variété d'industries se sont appuyées sur des mainframes pour exécuter des applications critiques pendant des décennies. Ces entreprises souhaitent naturellement moderniser leurs applications basées sur mainframe pour réduire les coûts et éliminer la dette technique, mais elles ne savent pas comment ni par où commencer », a déclaré William Platt, directeur général des services de migration chez AWS. « Avec AWS Mainframe Modernization, les clients et les intégrateurs de systèmes peuvent désormais refactoriser ou changer de plateforme plus rapidement et plus facilement aux applications mainframe pour qu'elles s'exécutent dans le cloud. AWS Mainframe Modernization fournit les outils nécessaires aux organisations pour tirer pleinement parti de l'élasticité, de l'évolutivité et de la fiabilité d'AWS, tout en économisant du temps et de l'argent ».


    Mais existe-t-il vraiment une telle demande pour migrer les applications des systèmes mainframe vers AWS ?

    De nombreux mainframes ont été acquis afin d'exécuter des services critiques dont dépendent les organisations, tels que CICS pour la gestion des transactions, et il est peu probable qu'ils soient déplacés vers une plateforme de cloud public.

    L'analyste en chef d'Omdia, Roy Illsley, est d'accord, affirmant que le service de modernisation du mainframe s'adressera probablement principalement aux clients qui utilisent déjà AWS pour d'autres charges de travail et qui ont peut-être des applications mainframe qu'ils voudront peut-être moderniser.

    « Le cloud n'est pas adapté à la plupart des charges de travail mainframe, et nos données ne montrent pas de migration massive de l'héritage vers le cloud. Je pense que c'est une offre dont ils ont besoin pour être complet », a-t-il déclaré.

    Le vice-président directeur de Gartner, Mike Chuba, a déclaré que de nombreux projets de migration mainframe qu'il a vus ne se sont jamais achevés, ainsi que ceux qui ont tendance à être de plus petits ateliers mainframe ou des applications qui ne sont pas critiques.

    « Le défi pour presque tous les utilisateurs de mainframe est que de nombreuses charges de travail sont souvent des applications critiques pour l'entreprise qui ne peuvent pas tomber en panne, car si elles le sont, l'entreprise est gravement menacée. En tant que tel, ils doivent être sûrs à 100% qu'une migration pourrait être faite, tout en veillant à ce que les SLA soient respectés », a-t-il expliqué.

    Le service AWS Mainframe Modernization est généralement disponible dès maintenant dans les régions AWS couvrant les États-Unis, l'Asie-Pacifique (Sydney), le Canada, l'Europe et l'Amérique du Sud, avec des régions supplémentaires qui seront ajoutées dans les mois à venir, a déclaré AWS.

    Source : AWS

    Et vous ?

    Que pensez du service géré AWS Mainframe Modernization ?
    Pensez-vous que les mainframes vont effectivement disparaître ou resteront-ils encore longtemps ? Pourquoi ?

    Voir aussi

    AWS présente une flopée de nouveaux services de bases de données et de ML, et annonce en Preview version RDS Custom pour Microsoft SQL Server et AWS DMS Fleet Advisor
    98 % des responsables informatiques envisageraient de migrer des mainframes vers le cloud, même si 96 % d'entre eux considèrent que les applications mainframe sont importantes, selon LzLabs
    AWS présente Proton, le service de gestion des conteneurs, pour automatiser le développement et le déploiement des conteneurs et d'applications "serverless"
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  13. #53
    Membre éprouvé
    Homme Profil pro
    retraité
    Inscrit en
    septembre 2014
    Messages
    454
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : septembre 2014
    Messages : 454
    Points : 1 098
    Points
    1 098
    Par défaut
    Attention, si vous votez "mal", si votre Gouvernement devient "agressif', alors vous subirez les mêmes sanctions que la Russie.

  14. #54
    Membre régulier
    Inscrit en
    octobre 2004
    Messages
    154
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 154
    Points : 110
    Points
    110
    Par défaut
    Bonjour à tous,

    J'ai fait 12 ans de banque et à mon arrivée, j'ai découvert COBOL via l'AS400 et les écrans 52/50. Au début, je me disais que c'était vieillot, ayant une vision de développeur web à l'époque (Asp, Php, .Net naissant).

    Puis je m'y suis mis par curiosité et j'ai adoré le langage COBOL.

    Quand je lis ceci de @thamn :
    > C'est important pour éviter ce qu'on appelle les bases de code monolithique et permettre la réutilisation. Base de code monolithique qui sont, d’après ce que j'ai pu lire, particulièrement typique du COBOL.

    Oui et non : Cobol hérite de son histoire avec les cartes perforées. Mais cela n'en reste pas moins un langage de programmation : il y avait des développeurs qui faisaient des appels à des sous programmes (que l'on pourrait apparenter à des méthodes réutilisables) et d'autres qui codaient tout d'un bloc. Mais ça, cela ne dépend pas du langage mais bien du dev et pour terminer sur ce hors-sujet, JPLAROCHE a bien expliqué les tenants et aboutissants du Cobol moderne.

    Maintenant, le souci de migration : en 12 ans, il a été évoqué une dizaine de fois et à chaque fois abandonné. Pourquoi ? Parce que le coût est trop important, le risque trop grand, que personne n'a connaissance de tous les programmes Cobol et qu'il faudrait en réalité retranscrire ligne à ligne chaque programme. Par exemple, les distributeur de billets ont un windows en front mais discutent en cobol en back.

    On a quand même fait une "demi" migration : on a exposé des endpoints (exposant du XML de mémoire) depuis l'AS400 et recréé certains écrans sur du MVC C#. Cela fonctionnait très bien mais le coeur "métier" est resté en Cobol... au moins, nous n'avions plus à gérer les écrans.
    Mais avec cette migration, on s'est aperçu que nos agents au comptoir perdaient énormément de temps avec la souris, qui n'existe pas vraiment sur les écrans 52/50 quand on maitrise les raccourcis.
    On a donc ajouté des raccourcis clavier qui se rapprochaient un maximum des anciens écrans mais le mal était fait : la nouvelle génération clique, l'ancienne ignore le mulot

    Maintenant pour la partie "réelle migration", la question était : où iront nos données ultra-sensibles (banque). Des acteurs comme Microsoft nous avaient contactés mais le fait que les données soient stockées à l'extérieur de la banque était impensable.

    Donc la seule solution a été de former des jeunes au Cobol ou de prendre des prestataires chez SOPRA de mémoire et il en est encore aujourd'hui ainsi d'après mes collègues même si la question de migration revient encore très souvent dans les discussions au siège.

  15. #55
    Membre à l'essai
    Homme Profil pro
    indépendant
    Inscrit en
    mai 2016
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : indépendant

    Informations forums :
    Inscription : mai 2016
    Messages : 12
    Points : 20
    Points
    20
    Par défaut Portekoi intervention
    Très bien, c'est ce que j'ai vu dans la réalité, ton intervention "éclaire cruement" le discours un peu commercial et un peu marketing de AWS.

    Il a aussi été indiqué par un ponte du Gartner que les migrations MainFrame --> Open se plantent toutes ?!?
    C'est faux , il y a des exemples, celui auquel je pense (Confidential, sinon, je citerais) qui a marché , c'est grâce au portage des points de fonction avec récriture complète pas une migration basée sur des moulinettes de code.
    Et c'est vrai, car si celles qui marchent sont des reprises à partir de la fonctionnelle, est ce vraiment une migration technique ?

    Enfin, dernier détail , le code sur MainFrame ( je ne connais pas du tout AS400) est rapide, voire très rapide, un portage doit non seulement fonctionner à l'identique , être épuré de dette technique mais aussi pédaler aussi vite que la version originelle y compris en cas de mode dégradé.
    Bref , ce n'est pas simple.
    Bonne journée à tous

Discussions similaires

  1. Réponses: 8
    Dernier message: 31/08/2018, 15h40
  2. Une start-up américaine veut remplacer les CAPTCHA par des jeux
    Par LittleWhite dans le forum Développement 2D, 3D et Jeux
    Réponses: 45
    Dernier message: 14/05/2012, 18h57
  3. [CSV] Remplacer les points par des virgules
    Par johnkro dans le forum Langage
    Réponses: 4
    Dernier message: 27/11/2008, 19h25
  4. Label d'axe graphique: remplacer les nombres par des mots
    Par Chrysomallus dans le forum MATLAB
    Réponses: 3
    Dernier message: 19/04/2007, 15h23
  5. [vb6] Remplacer les Frames par des PictureBox
    Par Christophe P. dans le forum VB 6 et antérieur
    Réponses: 3
    Dernier message: 10/07/2006, 16h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo