Le Mainframe est-il mort ?
Pourquoi se se poser cette question sur le Mainframe ?
Le Mainframe constitue la colonne vertébrale informatique de nombreuses entreprises. Le système de gestion de la plupart des banques et assurances repose notamment dessus. Mais de nouvelles pratiques récentes s’en affranchissent. Google par exemple n’y fait pas appel pour gérer son moteur de recherche, pourtant gestionnaire de plusieurs milliards de données.
Doit-on ainsi s’émanciper de ces macro-ordinateurs ? Et doit-on se libérer par la même occasion du Cobol, cet antique langage de programmation qui y est associé ?
Qu’est-ce que le mainframe ?
Le Mainframe est souvent assimilé à un gros ordinateur. Derrière ce rapprochement un peu grossier, le Mainframe se définit surtout comme un système informatique centralisé. Concrètement, il se compose d’une machine, avec un et plus souvent plusieurs OS installés dessus. Un système d’exploitation principal guide la machine et les OS secondaires sont souvent Linux ou Windows.
En prenant par exemple les z15 IBM, les machines les plus populaires, on peut mettre jusqu’à 5 systèmes en natif :
- • Le z/OS qui est l’OS standard.
- • Le VSE, soit de tout petits mainframes, adapté aux très petites configurations. On les retrouve dans les entreprises de moins de 10 salariés, ce qui représente tout de même 8% du marché.
- • Le VM, pour Virtual Machine, qui est orienté émulation, avec une capacité d’un millier d’instances de machines virtuelles et une virtualisation à 5 niveaux (création d’une machine virtuelle, qui va créer en son sein une deuxième machine virtuelle, qui elle-même va en créer une troisième, etc.). Il existe également une logique de conteneurs sur ce type de système. Pour donner une idée de la puissance, on peut aller jusqu’à 2,4 millions de conteneurs Linux sur une même machine. Mais si la puissance est comparable à des data centers, on se retrouve face à des machines beaucoup plus compactes et beaucoup moins chères à l’utilisation, notamment en termes de ressources consommées.
- • Le TPF, soit le système pour faire du transactionnel de masse, et ainsi privilégié dans le transport aérien notamment. Avec cet OS, la capacité monte à un billion de transaction par jour (1000 milliards), avec des dizaines de milliers de connexions simultanées. Mais cette puissance de calcul suppose évidemment des machines adaptées au niveau des serveurs et des processeurs.
- • La dernière option est de n’installer que Linux sur son Mainframe.
On entend souvent Mainframe égal Cobol. Si c’est effectivement le langage le plus utilisé, on comprend bien à l’énumération de ces configurations que le Mainframe peut également servir pour d’autres langages comme du Java ou du Node.JS. Et ce, sur la même machine grâce à l’intégration de plusieurs OS différents. Ici réside l’atout principal du Mainframe : tout centraliser sur une même machine – sans avoir à s’équiper de serveurs séparés – avec des outils et des langages différents. Ainsi, le Mainframe permet de résoudre les problèmes de liaisons et de décalages dus à des réseaux distincts.
Mainframe : pourquoi Cobol et Pacbase ?
De la même façon que Java est optimisé pour les applications web ou le C pour les systèmes, Cobol est le langage par excellence pour faire de la gestion. Il comporte deux atouts majeurs et exclusifs :
- • Les calculs en virgule fixe de manière native, ce qui permet précision en rapidité pour les décimales (à l’inverse des autres langages en virgule flottante), toujours très appréciable dans les métiers financiers
- • Les redéfinitions de données, qui permettent nativement – contrairement à la plupart des autres langages – d’isoler des variables sans extraction
Cobol a souvent l’image d’un langage vieillissant et complexe. Il est d’ailleurs de moins en moins enseigné, mais reste très utilisé, ce qui donne beaucoup d’importance aux personnes capables de l’instruire. Mais la mutation des entreprises, vers des méthodes agiles notamment, déteint sur les projets Cobol qui adoptent le système Scrum par exemple, abandonnant les cycles en V. Il faut toutefois s’attendre à des sprints plus longs, d’environ 3 semaines, pour avoir le temps de développer. Au contraire du Java, le Cobol ne permet de mettre en œuvre une évolution et de la présenter en temps réel (continuous development). Il faut alors se concentrer sur chaque fonctionnalité, pour à la fin des épics, présenter l’application dans sa quasi-globalité. Malgré cette particularité de travail, le langage Cobol fonctionne parfaitement en Scrum, et beaucoup de grandes banques et assurances ont franchi le pas ces dernières années.
Et si les pratiques DevOps ne sont pas encore envisagées, la particularité des Mainframes, avec leur abondance de systèmes d’exploitation embarqués, permettent néanmoins des passerelles entre les différents environnements que peuvent être les développements, les tests, les homologations, etc. Cette simultanéité contrebalance ainsi la relative longueur des sprints.
Le Cobol : vieux langage ?
Historiquement, le Cobol se veut être un langage interopérable, parce qu’il n’est pas le langage originel et que les personnes l’ayant construit ont souhaité pouvoir appeler d’autres langages.
Mais il a cette image de vieux langage, car il est toujours rétro-compatible alors qu’on ajoute des nouveautés. Le langage Cobol continue ainsi d’évoluer (version 6.4 sortie en mai 2022) et est capable de communiquer avec des nombreuses technologies comme du xml, du MQSeries, ou encore du JSON, grâce aux nouveaux ordres du langage. Le plus grand frein reste finalement le silotage de certaines entreprises qui compartimentent leurs équipes par technologie. C’est en fait la nature même du besoin qui va décider si des échanges entre les langages sont nécessaires.
Et comme pour d’autres langages, le Cobol s’appuie sur plusieurs gestionnaires de sources, comme zGit ou SVN. Cela dépend ici aussi des choix de l’entreprise. On observe ainsi sur beaucoup de points une volonté du langage de se moderniser. Le dernier exemple en date est le passage presque systématique à l’outil Eclipse au détriment de l’outil TSO, resté célèbre pour son surnom de Minitel, tant son interface y ressemble.
La part du business dans le mainframe
Le Cobol reste un langage très utilisé dans de nombreux secteurs d’activité comme la banque, l’assurance, mais aussi la grande distribution, l’industrie spatiale et automobile ou la Défense. Populaire en son temps, le Cobol est toujours au cœur des systèmes d’informations de ces secteurs et outre le coût, le temps et les risques liés à une migration, il a l’avantage d’être un des langages les plus sécurisés ce qui perpétue son usage. Et en termes de coût d’utilisation, le Cobol reste inférieur aux autres langages, surtout à long terme, car la durée de vie de son code est plus longue et il n’est pas nécessaire de le réécrire dès que le langage évolue, comme avec du Java par exemple.
Malheureusement, son image vieillissante fait que de moins en moins de développeurs maîtrisent ce langage. Le marché se retrouve donc avec une pénurie de compétences en Mainframe alors que les besoins restent a minima stables. Pourtant, la mauvaise presse du Cobol semble exagérée. Le Cobol reste un langage relativement simple qui permet d’accéder à des projets à dimension fonctionnelle stratégiques que ne permettent pas d’autres langages plus modernes comme le .net ou le Java. Le sens du marché s’apparente ainsi à une double maîtrise Cobol et langage plus orienté objet (JS ou Java par exemple), afin, pour les entreprises, de disposer de compétences transversales, et pour les développeurs, de participer à des missions beaucoup plus valorisantes et complètes.
Non, le Mainframe n’est donc pas mort. Au contraire, il est plus vivant que jamais, parce que les besoins ne diminuent pas au sein des entreprises, et, alors qu’il est de moins en moins enseigné, il devient de plus en plus rare et donc recherché.
