Applications COBOL: Les belles anciennes

L'informatique connait actuellement un certain nombre de mutation. Les smartphones,les tablettes  le cloud, les réseaux sociaux , le NoSQL et le bigdata: des mots qui rythment les avancées technologiques. Mais on oublie vite qu'il reste des milliers de programmes COBOL comportant des millions de ligne . Sur ces programmes reposent l'ossature des traitements réalisés par les Administrations, les Banques ou les assurances. Ces applications sont un peu les oubliées de l'informatique. Elles sont portant  des belles anciennes.

3 choses à savoir au sujet de ces applications:

1 ) Il ne reste que le meilleur.... et le pire

Dans la plupart des cas  les applications restantes sont bien écrites , seuls les meilleurs programmes ont survécus , un peu comme une sélection naturelle. Un mauvais programme , mal écrit , sans évolution possible parce que trop complexe a déjà fait l'objet d'un portage vers des technologies plus modernes. Il reste le haut du panier des programmes COBOL. Hélas à coté de ces bons élèves se trouvent des programmes 'stratifiés'. Chaque évolution faisant l'objet d'un empilement supplémentaire.

2) Coût de maintenance.

Elles ont un coût d'entretien  faible car elles sont sûres  Elles ont tourné  des millions de fois avec des cas de figure inimaginables. Chaque recoin de l’application a été testé en réel. Le coût de correction d'une application COBOL est moins élevé que pour une application J2E

( 5,42 $ par ligne de code Java , tandis qu'une erreur sur Cobol ne coûte que 1,26 $)  

source: http://www.lemondeinformatique.fr/actualites/lire-erreurs-de-programmation-java-coute-plus-cher-que-cobol-46976.html

3) Lecture simplifiée de l'algorithmie des programmes COBOL 

La composition d'un programme COBOL facilite sa prise en main.

Sur 100 lignes de programmes COBOL seules 20 implémentent directement la partie métier. Les autres servent à mettre le programme en relation avec son environnent (ENVIRONMENT division ) 

ou à définir les données à traiter (DATA division). L’algorithmie est regroupée dans très peu de ligne dans la PROCEDURE division. Ce phénomène  de concentration ne se retrouve pas dans des programmes issus d'une approche objet hébergés au sein d'un framework: on assiste dans ce cas un éparpillement façon puzzle de algorithmie générale du programme.

Façon puzzle : RIP

Les coûts.  

Aussi, les coûts / risques  des anciens programmes  (legacy) viennent d'un part de l'infrastructure MAINFRAME à entretenir  (licence et matériel) et d'autre part de la perte de compétence sur la partie métier (absence de documentation générale) . 

La  génération des programmeurs COBOL va arriver à l'age de la retraite. 

Je recommande aux jeunes ingénieurs de passer par la case 'COBOL' pour booster leur carrière 

Le retour des disques vinyles

Alors que faire ?

Cette question revient souvent dans les forum comme quora.com

A la question: pourquoi les banques continuent à utiliser leurs programmes  COBOL ?

Voici une des réponses qui résume bien: 

J'ai travaillé dans l'autorité de conception technique pour Natwest Bank et Royal Bank of Scotland. Ceci est un résumé de ce que le chef de la stratégie technique m'a dit une fois:

Le montant d'argent que la banque a investi en COBOL et d'autres technologies plus anciennes est massive.

Cet immense investissement au cours des décennies a abouti à un système bancaire de base qui a des capacités qui ne sont pas reproduits par les éditeurs de progiciels. 

Personne ne sait vraiment comment l'énorme monticule de code spaghetti fonctionne réellement. Le projet de reverse engineering   serait un projet gargantuesque.

Les projets gargantuesques ne sortent jamais

Et quel serait l'avantage - le système fonctionne comme il est.

Architectures orthogonales

J'ai entendu une fois l'expression 'architectures orthogonales'  sans avoir plus de détail.
En piochant à droite et à gauche, on imagine que cette notion fait référence aux des
 architectures verticales et horizontales.

Le modèle 3tiers

On a d'un coté des modèles d'infrastructure en 'tiers' avec généralement 3 tiers:
Le serveur web , le serveur de traitement (applicatif) et le serveur de données (SGBD) .

La conception MVC

A cette spécialisation  des rôles  s'ajoute un découpage fonctionnel en couche MVC 

Le serveur applicatif met en oeuvre un ensemble de design pattern: Model Vue Contrôleur (inventé bien avant le WEB) 

Et le reste: OOP , OS

A ce mille-feuille vient s'ajouter les couches liées au développement en approche objet puis celles du système d'exploitation.

Et donc..

On se retrouve avec un empilement de module , de composant de nature et de taille hétérogène.

Or quel est l'objectif:  Offrir un service de qualité à nos utilisateurs. Ici intervient la notion de scalabilité. Comment supporter un nombre d'utilisateur plus important avec des volumes de données en hausse ?.

A chaque fois le problème est botté en touche en direction des  responsables d'infrastructure. 

Leur  seule  réponse possible est  d'augmenter le nombre de serveur pour doubler, tripler les composants. 

Mais empiler des briques hétérogènes fragilise la stabilité de l'ensemble. C'est coûteux pour un rendement marginal décroissant.  Car cet empilement ne donne pas un rendement d’échelle linéaire. 

Il faut trouver des systèmes pour partager des sessions serveurs , gérer des caches à tous les niveaux, des répartiteurs etc.  bref le prix à payer est élevé. 

La scalabilité horizontale consiste à augmenter le nombre de machine. La scalabilité verticale vise à augmenter la puissance unitaire des machines.  L'orthogonalité cherche à combiner les deux approches en par une simplification des architectures.

Vers des architectures pus simples et ... moins coûteuses.

La première règle à mettre à oeuvre est de réaliser des applications avec des architectures simples avec moins de couche.

Règle 1: simplifier les couches d'abstraction: chaque abstraction coûte et ajoute de la  complexité  

  

Avez vous besoin de faire une application métier de gestion ou un site de publication ?

Si la réponse est 'une application métier' , vous n'avez pas besoin d'un serveur web complet pour votre application.  

Votre choix doit se tourner vers des serveurs applicatifs à gestion d’événement non bloquants et asynchrone  (Non-bloking I/O event loops) comme Node.js pour javascript , VertX pour Java ou eventmachine pour ruby.

Et des mico-frameworks comme Express ou Sinatra. 

Dans ces technologies , le développeur  travaille directement son cœur de métier: la mise à disposition de ressources. Il n'est plus tributaire de la configuration lourde d'un serveur HTTP.

Un process en attente sur un serveur =  gaspillage de ressource = les serveurs vous font les poches.  

Règle 2: Réfléchir en terme de conteneur autonome. 

Votre application doit être l'assemblage de briques identiques autonomes. Ces briques ne doivent pas gérer ou partager des sessions. Celles ci sont prises en charge par le client (REST: les requêtes sont autonomes

Ce qui implique aussi que chaque conteneur accèdes à des données dans son contexte. 

Aussi un conteneur embarque : une couche HTTP, l'application métier et le backend de stockage.

Comment passer d'une architecture 'classique' à une architecture moderne. 

• Tout d'abord la partie applicative:

• Puis la partie frontale :

Pour accéder aux conteneur, il est possible de placer en frontend le serveur NGINX. Ici ,il n'est pas utilisé comme un serveur web mais comme un reverse-proxy avec des fonctionnalités de répartition de charge.

• La partie backend ou stockage:

L'usage d'une base NoSQL viendra compléter le dispositif et rendra chaque 'nœud' autonome les uns par rapport aux autres.

•  La partie SSO  peut elle aussi être implémentée sur chaque nœud: 

  

Ici , il n'est plus question de SSO préemptif ou coopératif: on est dans un mode de micro-SSO 

Pour aller plus loin.

L'idée générale est d'obtenir des boites identiques autonomes un peu comme ceci :

Permettant empilements à la fois verticaux et horizontaux = Orthogonaux  = des constructions solides.

Le site Colbert 2.0

Le ministère du Redressement productif a mis en ligne sont outil Colbert 2.0 destiné à calculer les gains de relocalisation. Quel est l'architecture du site ?:

- Le moteur est en PHP sur un serveur Apache.
- Utilisation de jquery pour faciliter les échanges avec  l'utilisateur
- Utilisation du framework 'Bootstrap' pour la mise en page et le design.

Bootstrap est une collection de javascript , de feuille de style (CSS) qui permet de réaliser des sites web bénéficiant des dernières avancées ergonomiques. Bootstrap permet de gèrer des affichages sur mobiles ou tablette : (responsive design) , le projet est porté par les équipes de twitter. 

mongodb : premiers pas avec cette base nosql

Et une vidéo de plus consacrée à mongodb: Les premières manipulations

Le support est en ligne ici :

Mongodb101 support de la video pour débuter from eric german

La partie vidéo seule est ici:



Les sujets abordés sont les suivants:

j'evoque l'injection massive par la commande mongoimport
La syntaxe est la suivante:

./mongoimport --file ../../stations.json --collection stations --db velibdb --jsonArray

Le dernier paramètre (jsonArray) sert à indiquer que les documents JSON sont  les uns à la suite des autres dans un tableau.

J'utilise un fichier opendata sur l'état des stations  Velib issu du site: http://eaupen.madebymonsieur.com/velib

Le programme ruby  servant à mettre à jour  les informations des stations est donné ci-dessous:



Les prochaines vidéos porteront sur les recherches dans une base mongoDB.

Une première introduction à la base NOSQL mongodb

J'ai mis en ligne une nouvelle vidéo consacrée à  mongodb.
Le site de mongodb est ici.



 Le support complet slides et vidéo est sur le site de partage slideshare

Mongodb introduction from eric german


MongoDB et Haddop sont deux compagnons.  Hadoop permet de stocker des volumes importants  et mongoDG s'occupe de la restitutions d'extraction de données venant d'hadoop.
Dans le sens inverse, mongodb peut utiliser la puissance des JVM pilotée par Hadoop pour réaliser des traitements par lots (ex Map-reduce).

MongoDB est une base NOSQL  de type document un peu comme couchDB. Son langage de commande est le Javascript.  Le projet se compose d'une série de programme dont 'mongod' : le serveur de la base et 'mongo' : un client sous la forme d'une console shell.

J'ai mis ici un exemple de script de lancement du service mongod pour ubuntu
 

Et ici le fichier de configuration:

Bientôt des vidéos et des articles sur la base NoSQL MongoDB

Voila plusieurs semaines que je bricole avec MongoDB l'étoile montante des bases NoSQL  (Not Only  SQL).

 Après avoir essayé: CouchDB , Redis , Riak , étudié Cassandra et Hadoop (voir les posts ou les vidéos)

(source : http://germanlinux.blogspot.fr/2012/12/la-carte-hadoop-pour-ne-pas-se-perdre.html )

Posts :

• Hadoop , mongoDB : http://germanlinux.blogspot.fr/2012/12/la-carte-hadoop-pour-ne-pas-se-perdre.html  (8/12/12)
• NoSQL : théorème de CAP :http://germanlinux.blogspot.fr/2012/01/hadoop-les-limites-des-nosql.html (9/01/12) 

C'est lors de la journée des utilisateurs Hadoop France en decembre 2012 que j'ai compris l'importance du rôle de MongoDB.

Il y a d'un coté le BigDATA:
Il   répond à un besoin de stocker un nombre vertigineux de données et surtout à offrir un cadre pour réaliser des traitements parallèles (map-reduce)

De l'autre  coté le mouvement NoSQL qui cherche à assouplir  l'architecture applicative et à simplifier les modèles de données. Le NoSQL souhaite aussi répondre au besoin de stockage de masse engendré par les réseaux sociaux. Ces informations ne sont pas toujours structurées . La disponibilité, le partage des données sont les objectifs principaux, le traitement parallèle est secondaire.

MongoDB fait le lien entre ces deux mondes.
 

Prochaine vidéo

A bientôt.

Le cloud: le juge de paix des architectures applicatives

Le cloud se veut une réponse  agile et souple à nos besoins en services informatiques.  Mais il se révèle aussi comme un élément structurant qui influence l'architecture des applications informatiques.

Prenons trois exemples:

Deux applications identiques

 Les applications A et B sont identiques en terme de fonctionnalité, du nombre d’utilisateur etc.
Pourtant chaque mois la facture du fournisseur du cloud sera pour l'application 'B' trois ou quatre fois plus chère que pour l'application 'A' : pourquoi ?.
L'utilisation du cloud n'est pas gratuite, le coût dépend de l'usage.  La réponse est simple: dans l'application 'A' la grande partie des traitements  est réalisée sur le poste client. La partie cloud ne sert qu'a délivrer une application complète qui ne fera appel au cloud que pour la récupération des données.
C'est l'utilisateur qui supporte une plus grande partie des coûts en utilisant la puissance de calcul de son poste.

Ce raisonnement est amplifié dans le cadre d'une entreprise qui utilise un cloud privé ou public: elle supporte un double coût: La partie cloud et la partie poste de travail. Cette dernière étant obligatoire: chaque employé est doté d'un poste de travail.

2eme exemple la scalabilité.

Le cloud est avant tout élastique. La puissance mise à la disposition doit pouvoir s'adapter (dans les deux sens) en fonction de la demande. Vous n’êtes pas face à un cloud s'il faut deux jours de délais pour obtenir une machine virtuelle supplémentaire. Au contraire , ces ajustements doivent pouvoir être administrés par des commandes à votre disposition.
Mais toutes les applications ne sont pas 'scalable' de la même manière. Si votre application utilise un serveur de session  (en base par exemple) l'ajout de serveur applicatif va se heurter à des problèmes de disponibilité des informations de session. Aussi, il est préférable que la session soit portée par le client afin de libérer la partie serveur d'une tache complexe et coûteuse.  Ce déport concerne   les traitements , le stockage coté client. Il est favorisé par l'utilisation d'architecture de type REST.
Sans état: Chaque requête d'un client vers un serveur doit contenir toute l'information nécessaire pour permettre au serveur de comprendre la requête, sans avoir à dépendre d'un contexte conservé sur le serveur. Cela libère de nombreuses interactions entre le client et le serveur.
https://fr.wikipedia.org/wiki/Representational_State_Transfer

3eme exemple: Les nouveaux terminaux: smartphone-tablette

Un des critères de qualité important pour une application pour les terminaux mobiles est la consommation électrique. Aussi , une application qui est obligée d'échanger en continu avec le serveur va  vider les batteries du terminal. Les applications voraces sont vite abandonnées par les utilisateurs. D'où l’émergence d'un type d'application qui embarque les traitements et une partie des données. L'application travaille de manière autonome et se synchronise de temps en temps avec votre cloud.
Ces application sont de type single-page application alias SPA en anglais
http://fr.wikipedia.org/wiki/Application_Web_Monopage

source :http://net.tutsplus.com/tutorials/javascript-ajax/important-considerations-when-building-single-page-web-apps/

En conclusion: toutes les applications ne sont pas taillées pour aller sur un cloud. Le choix d'une architecture applicative doit se conformer aux contraintes du cloud y compris dans sa logique de tarification: partager les coûts avec l'utilisateur en mutualisant la CPU et la mémoire.

Prochain épisode: dessine moi un cloud.