Bonjour,
Quelqu'un connait t'il une entreprise qui aurait fait une migration de ce type, c'est à dire, migrer un mainframe complet Zos (programmes COBOL, batch et TP, CICS, DB2,etc...sur Unix ou Linux ?
Merci
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
Migration Zos vers UNIX/LINUX
Bonjour,
Quelqu'un connait t'il une entreprise qui aurait fait une migration de ce type, c'est à dire, migrer un mainframe complet Zos (programmes COBOL, batch et TP, CICS, DB2,etc...sur Unix ou Linux ?
Merci
Bonjour,
Au vue du travail a effectué pour une migration complète (réécriture des applications...), je me demande si une l'a déjà totalement réalisée (sachant que le mainframe est utilisé pour des structures assez grande, donc beaucoup d'applications et je pense que il y a pas mal de boulot pour optimiser la performance et la sécurité [peut être a tort]) .
L’entreprise pour laquelle je travaille souhaite abandonné le mainframe pour une architecture totalement distribué (pour l'instant cohabitation) mais se projette sur une durée de 10 ans pour tout migré.
bonjour
Migrer toutes les appli z/os vers unix/aix/linux! un travail de ouf quasi impossible à réaliser (les contraintes techniques ne sont pas les mêmes)
Par contre, de nombreuses sociétés ont des ateliers de dev (ont des "fermes" de programmeurs à dispo) capables de transformer tout en n'importe quoi (ou l'inverse).
Bon courage pour mettre la main sur la bonne société (trop de critères à prendre en compte).
a+
idée d'une rare débilité ... enfin bon, si ils ont de l'argent a jeter pat la fenêtre ...Envoyé par tbeghain
bonjour,
démarche effectuée chez Canal+ que je trouve très élégante et aurais aimé réaliser dans mon entreprise, pour l'interret technologique que l'exercice représente
sinon, j'ai entendu parlé d'une telle opération au PMU vers une solution type Power7/AIX/Tuxedo/Cobol que personnellement je trouve beaucoup moins Fun, mais je crois que le projet prend pas mal de retard
Je n'ai pas compris la remarque de Luc orient.Si les entreprises le fond, c'est qu'il y a un minimum de retour sur investissement sinon pourquoi se prendre la tête par rapport a une architecture qui est "vissée" et développée depuis x années.Je n'aurais pas de connaissances suffisantes sur la protection et les possibilités qu'il y a par rapport au mainframe mais au moins les dépenses d'exploitation devraient être moins salées,non?
Aaaah...
Justement les coûts sur mainframe sont extrêmement plus faibles "en proportion".
La démonstration est très classique et se fait en plusieurs parties :
LE PERSONNEL
Là où tu devras poser plusieurs administrateurs pour gérer une "ferme" de serveurs + les logiciels + les applis, et espérer qu'aucuns ne tombent, tu as 2 possibilités :
- embaucher BEAUCOUP de personnel où chacun va gérer une couche... et un nombre maximal de machines
- demander à un tiers de gérer ça... avec des SLA qui imposeront des "grosses" pénalités en cas de pannes => il prendra la décision de "risquer" une pénalité financière OU d'embaucher autant que l'entreprise aurait dû
Le mainframe va réduire drastiquement le nombre de machines, mais, il nécessitera des compétences rares.
Du coup tu réduis le nombre de personnes "nécessaires" au fonctionnement, et donc pas mal de managers + RH pour gérer cette masse salariale.
LES MACHINES
Là où une centaine de machines fonctionnent.... tu te doutes grandement qu'il faudra :
- de la clim'
- de l'élec'
- sécuriser physiquement tout ça
- mettre du réseau partout (des câbles des câbles des câbles.....)
- mettre des sondes et des switchs et des routeurs.... (encore pluuuuuus de câbles entre tout... et de l'élec nécessaire)
- ...
Bref, tu vas devoir sortir l'artillerie TRES lourde "seulement" pour ces machines.
Avec "un" mainframe (donc l'équivalent de 4 baies environ), tu vas réduire physiquement la place prise ET la consommation !
Donc des économies en vue.
Aujourd'hui, Ubuntu est annoncé en complément de Suse et Red Hat sur le Z.
Donc si tu es une entreprise utilisant BEAUCOUP de machines, c'est probablement une bonne idée de réduire l'ensemble des coûts de maintenance => moins de changement de machines à faire, moins de spare à conserver, etc....
Bref : à moins que l'entreprise qui souhaite se passer de son Z ne l'utilise quasiment pas (ils utilisent le plus petit des mainframes IBM, et en plus ils l'utilisent peu), c'est une aberration de vouloir le quitter.
Un mainframe peu utilisé est en effet une source de coûts car pour peu de charge CPU, le coût "autour" de la techno est élevé.
Mais une "grosse" banque ne pourra certainement pas tenir longtemps sans.
J'oubliais un autre point important : une fois que la décision de la migration Z -> Distribué est prise... il va y avoir un certain coût pour cette migration.
Cela va inclure l'étude du périmètre, la préparation des machines/logiciels/applis (de l'achat de machines et de licences sans utilisation directe pour l'utilisateur final) pendant que le Z fonctionne, recrutement du nouveau personnel et/ou formation de l'ancien personnel, réécriture des applications, et enfin tous les tests de fonctionnement.
Selon la taille de l'informatique de l'entreprise (et en fait TOUTE la problématique tourne autour de cet unique facteur), cela peut être rapide et peu coûteux (mais il est improbable qu'un mainframe soit déjà en place), ou alors extrêmement long, voire annulé.
Le premier problème va donc être en cas d'annulation du projet de migration : tout l'argent dépensé est perdu.
Et tu te retrouves avec des gens trop formés ou du personnel en trop "inutile", des licences inutiles, des machines inutiles... et ça prend de la place + des charges sociales...
Donc non seulement l'argent du projet est perdu, mais en plus tu as ajouté des coûts de run.
Le deuxième problème, selon que la migration se fait au fur et à mesure ou d'un coup (impossible) : chaque partie que tu fais migrer du Z vers le distribué.... eh bein elle devient "ancrée" dans le distribuée comme elle l'était dans le Z avant.
Donc une annulation nécessitera un AUTRE projet de remigration vers le Z => tu perdras l'argent comme vu au 1er problème + tu devras en dépenser de nouveau pour remettre tes applications dans l'état précédent (et je ne parle pas de sauvegarde du "contenu", mais bien de la chaîne logicielle)
En bref : soit l'entreprise est suffisamment petite au niveau de son IT pour se passer d'un mainframe vieillissant, en effet.
Soit c'est une décision "mauvaise" de la part d'un manager qui n'a pas compris que son IT est beaucoup plus vaste que ce qu'il pensait.
Dans les 2 cas, il faut faire un plan exact de son architecture technique pour se rendre compte de la réalité... et surtout des raisons qui ont motivé l'utilisation d'un mainframe jusqu'à maintenant.
J'ai compris le raisonnement mais pour les grosses structures, avec des gens plus ou moins compétents dans tout les domaines (finance, étude archi, méthode), j'ai du mal a penser qu'une migration si elle est décidée ne soit pas complète (et hop, on oublie tout : les sous dépensés etc) et dans le cas de cette décision qu'il n'y ai pas une étude antérieure sur l'impact positif au moins au niveau des coûts (nerf de la guerre).
Erreur....les grosses structures, avec des gens plus ou moins compétents dans tout les domaines (finance, étude archi, méthode)
Les grosses structures sont composées de personnes avec de l'ancienneté !
Mais pas nécessairement celles qui ont les meilleures formations pour prendre certaines décisions, ou les meilleurs conseillers.
Il existe beaucoup de problèmes "politiques" où le directeur 1 ne peut pas voir le directeur 2...
Ou encore un directeur qui a eu une mauvaise expérience dans sa jeunesse avec une entreprise, et fera TOUT pour arrêter les contrats avec celle-ci une fois à un poste de décision...
Il y a aussi les personnes "un peu trop" patriotiques de l'époque de Bull et autres, qui une fois placées à la tête de certaines entreprises ou SI, ont décidé de retirer tout ce qui était américain...
Et enfin, il y a le copinage : un directeur de l'entreprise 1 est ami avec un de l'entreprise 2... qui pousse à prendre les solutions de l'entreprise 3, car il est ami avec....
Bref, le postulat que les personnes haut placées "savent" ce qu'elles font est faux dans certains cas (enfin elles savent "pourquoi" elles prennent cette décision, mais elles ne savent pas toujours que ce n'est pas la bonne).
Il y a beaucoup de raisons "non financières pour l'entreprise" et "non techniques" qui font qu'une entreprise va choisir telle ou telle solution.
Je rejoins metalman, bernard59139 et Luc Orient (cf. supra), jamais vu de DSI migrer intégralement vers Unix / Linux.
Cependant, pour des applications délimitées, j'ai participé à la migration pour Groupama (fin 90's), d'applications issues des mainframe (IBM Z/OS & Bull Gcos 8) vers un environnement Unix en tant que référent Système et Production :
Sacré changement de culture en interne, relations Etudes/Production plus que tendues (comme d'habitude chez les grands comptes) mais au final une réussite tant technologique que humaine, une de mes meilleures expériences professionnelles que je cite encore en entretien ! (et çà passe comme une lettre à la Poste).
Pour rappel, de mémoire, l' écosystème Mainframe dans le secteur banque / assurance génère encore de nos jours jusqu'à 70 % du chiffre d'affaire.
[Edit] Et pour COBOL, le rapport Salzman sur son blog ci-dessous :
http://rapportsalzman.blogspot.fr/20...-pas-mort.html
Rapport Salzman: Le Cobol n’est toujours pas mort
[Edit2] toujours pour le COBOL :
https://fr.wikipedia.org/wiki/Grace_Hopper
si justement, CANAL+ vient de le faire en mai dernier.
honnetement je trouve la démarche osée mais très élégante dans la mise en oeuvre et j'aurais adoré participer à ce projet de transformation. comme le dit l'article canal ne cherchait pas au départ à faire des réductions de cout mais cherchait à apporter de l'agilité à son SI et donc ses offres et services dans un contexte fortement concurentiel.
la solution retenue d'utiliser un Cloud privé chez Amazon pour des archi type Iaas , voir Saas , au départ pour mettre à disposition des équipes de Dev des environnements très rapidement puis d'étendre le concept à la production est innovante.
personnellement je pense que l'avenir se situe vers des archi de type Cloud beaucoup plus scallable que les gros serveurs actuels que ce soit mainframe ou open (genre Solaris ou Aix) d'ailleurs.
tout le dev mainframe à été réécrit java / AngularJS ou été intégré en progiciel. Ca aurait été plus difficile à faire dans les temps pour une banque/assurance , cela dit.
La mise en oeuvre du projet a du couté très cher vu les 18 mois de délai mais je pense que l'avenir des infra se dirige vers ce type d'architecture horizontal scalling pour des raisons de scallabilité, d'agilité et aussi de cout, une VM sur du X86 ça ne coute rien. l'archi peut évoluer en meme temps que les augmentations de charge, l'investissement s'en trouve réparti dans le temps. le mainframe aura du mal à résister. ça se résume souvent par une histoire de cout mais à mon sens c'est plutot la rigidité d'usage des "gros" serveurs qui devrait être mis en avant.
Les cout récurent d'une telle archi n'est certainement pas plus cher que celui d'un mainframe (allez voir l'offre Amazon et ce que coute la mise à dispo d'une VM, c'est ridicule comme prix..); par contre cette infra apporte un niveau d'Agilité inégalable. ce genre de ROI est difficile à calculer mais sur du long terme on est forcement gagnant.
J'imagine assez la fin des gros centres de service informatique dans les 10, 15 prochaines années et une orientations vers des clouds semi privé mutualisés.
Les centres "privés" de données devraient se réduire, je suis d'accord.
Mais je ne les vois pas disparaitre intégralement.
Et je "pense" que l'ouverture à Ubuntu + l'ajout de KVM sur le Z est un pas dans cette idée de flexibilité : plus besoin de former des experts sur des technologies ultra-spécifiques, une partie de la connaissance sera déjà acquise grâce aux technos "open".
Mais je continue à croire que les optimisations du mainframe sont meilleures que celles des autres plateformes, et resteront nécessaires dans certaines conditions.
Merci pour cette information mais Canal+ n'est ni une banque ni une assurance.
Tout à fait, ce n'est pas pour rien qu'IBM investit dans Linux (via Red Hat de mémoire) et l'Open source en général.
Les besoins ne sont probablement pas les mêmes pour la banque /assurance et jusqu'à aujourd'hui on n'a pas trouvé mieux que l'attelage Z/OS / Cobol / CICS / RACF pour traiter des millions de lignes en toute rapidité et sécurité; mais, effectivement, il se peut qu'avec l'arrivée des "jeunes générations" et d'une certaine maturité technique, "le rubicon" soit franchi.
Et on peut très bien faire du Cloud sur du Mainframe, avec Linux sur System z. Ici le coût d'une machine virtuelle est dérisoire, si une machine z est déjà en place. Avec les fermes de serveurs x86, la capacité des serveurs physiques est atteinte plus rapidement, et il faut sans cesse en rajouter... Pour le z, on utilise la puissance déjà présente, et si il y en a pas assez, on en rajoute à chaud (possible dans la plupart des cas) !
Linux sur System z reste Linux, donc on peut très bien mettre toutes les dernières technos dessus.
En d'autres termes, Canal+ aurait très bien pu tout migrer sur zLinux, mais est-ce qu'ils ont au moins envisagé cette opportunité et comparé les coûts globaux ?
@xfanx
Je viens de lire avec du recul l'article particulièrement intéressant que tu nous a fourni.
Nulle part il est écrit que toute la DSI est "dans le cloud" et surtout pas les données client, seules celles qui sont non-nominatives le sont (ouf !).
D'autre part, la DSI de Canal+ parle de SI from scratch (ou plutôt le journaliste), c'est à dire d'une réécriture des applications côté, donc, études et développement et mise en production (cf. la démarche DevOps).
Jusqu'à preuve du contraire, les données "back-office" sont toujours hébergées chez leur infogérant sur le Z/OS (cf. les articles concomittants du MagIt) et traitées à priori par des équipes dédiées.
Enfin, il est intéressant de noter que la DSI réinternalise une partie de ses équipes IT dispersée dans les 80% d'externalisation avec l'appui d'une société de conseil/mise en oeuvre pour ces nouvelles technologies.
Migration Zos vers un Cloud
Je viens de trouver ce topic et il me semble intéressant de contribuer.
Migrer un système Zos vers une architecture cloud pose un certain nombre de problèmes techniques dont ceux de trouver un équivalent pour tous les langages ou utilitaires utilisés sur le Zos et ils sont potentiellement nombreux.
On doit donc factoriser les technologies pour les faire converger vers des technos pouvant être exécutées sur un cloud.
Sur les Main Frame Zos, on trouve par exemple :
- Des L4G qui génèrent du COBOL, tels que PACBASE, TELON, CSP, EGL, EASYTRIEVE...
- Des langages compilés : Natural, PL1, IDEAL,...
- De l'assembleur
- Des bases de données qui ne sont pas relationnelles : DL1, IDMS,...
- Des utilitaires : SPITAB par exemple
Un projet de downsizing doit conserver le service rendu. La migration doit être iso-fonctionnelle, iso maintenable et iso-performances.
De plus, le TP repose sur un moniteur transactionnel, le plus souvent CICS.
Migrer vers un cloud nécessite de :
1. Convertir TOUS les langages vers un langage compatible avec la plate forme cible. Le choix le plus rationnel étant COBOL et java. Il est nécessaire de disposer de traducteurs des différents langages sources vers COBOL et java. Le code cible devant être lisible et maintenable. Il n’est donc pas possible de juste transférer le code généré par les AGL source qui est illisible et impossible à maintenir (Les AGL n’existent pas en cible),
2. Migrer la base de données vers une base relationnelle ce qui implique de simuler sur la base cible les accès hiérarchiques ou réseau des bases sources pour ne pas avoir à modifier la cinématique des programmes sources. Tenter de la faire serait aussi compliqué et couteux que de réécrire et interdit une conversion par automate de transformation,
3. Remplacer les utilitaires par des équivalents sur la cible,
4. Traiter la problématique du moniteur transactionnel,
5. Démontrer l’iso fonctionnalité et donc mener des campagnes de tests de comparaison Source/Cible
Les solutions d’émulation MVS comme celle de Microfocus ne couvrent pas toutes les technologies et ne sont pas cloud compliant.
De plus si on migre vers une nouvelle plateforme, on a envie de disposer de ses avantages.
La solution la plus aboutie que je connaisse est celle de Move Solutions www.movesol.com qui est une SSII spécialisée qui convertit tous les langages en cobol et java ou .net, encapsule les transactions cobol dans des services web et implémente les fonctions du moniteur transactionnel dans un serveur d’application, fournit sans cout de licence des utilitaires de remplacement.
Cette solution permet de sortir vite du Zos et de faire rapidement des économies
(On divise par 10 les couts entre un Zos et un cloud privé !).
Les nouveaux développements peuvent être faits au choix dans l’ancienne techno, dans la nouvelle (java ou .net) ou dans un mix des deux. Cela permet de ne pas avoir de rupture dans la maintenance qui peut continuer à être assurée par les équipes en place qui pourront évoluer tranquillement vers les nouvelles technos. Il ne faut pas oublier les aspects RH et continuité de service.
La France est un peu à la traine pour sortir des Zos, mais en proche Europe des projets sont lancés un peu partout.
Tout le monde devra suivre car les premiers auront pris un avantage concurrentiel sur les couts de gestion des opérations traitées sur le cloud vs mainframe.
Je pense que c’est inéluctable.
Bonjour à tous
D'autres sociétés ont également fait ce style de migration :
La CNAF
Darty
Club MED
Des sociétés comme Lzlabs, Metaware en sont les spécialistes
Je crois que c'est dans l'air du temps ... et faisable !
Maintenant sur le gain engendré, la périnité , difficile de répondre !
Bonne soirée
Il serait intéressant de connaître aussi ceux qui ont échoué devant une telle migration avec souvent, des budgets conséquents engloutis en pure perte.
Mais bien sûr, on n'en saura rien car jamais aucune organisation ne communique sur les projets en son sein de ce style qui ont totalement échoué ...
Bien sûr que cela est possible et faisable. Au prix d'un investissement énorme et d'un risque important. Et quid de la qualité de service une fois la migration technique terminée ? C'est d'ailleurs pour cela que bon nombre de projets de ce type échouent...
Répondre avec citation
Partager