Auteur Sujet: Multi-tenant ready,  (Lu 1354 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne JPL

  • Bureau
  • Membre Senior
  • *****
  • Messages: 235
    • Voir le profil
Multi-tenant ready,
« le: 06 Septembre,2011, 08:18:15 »
 
« Le carrelet n’a pas pu attraper le reflet des étoiles » Poème Japonais


Google et Oracle ont remarqué que les systèmes d’information croulent aujourd’hui sous la complexité. Selon eux, beaucoup d’entreprises ne s’en relèveront pas sans un changement profond. En effet, deux architectures se font concurrence : le PCs/serveur lourd et l’architecture intégrée héritée de l’ AS/400. Google et Oracle nous décrivent quelques concepts de base afin de résoudre ce qu’il convient d’appeler une crise majeure du logiciel due à la complexité. Dans la lettre RePeGlio de ce mois nous passons en revue quelques uns de ces concepts novateurs: le client léger, l’intégration matériel/logiciel et le multi-tenant.

-) Client léger :

Par définition, seul le langage de présentation écran en mode caractères est transporté via le réseau et en aucun cas les données des fichiers. C’est le principe même du langage HTML ou du flot 5250. Typiquement, les données de l’écran sont peuplées dynamiquement par le programme côté serveur. Ensuite après un périple à travers le réseau, le langage de présentation parvient au browser qui construit l’écran final, tel qu’il sera vu par le client demandeur. Le browser côté client est doté d’un logiciel  spécialisé dans le traitement de la présentation de l’écran en cours, à partir d’un flot 5250 ou HTML. Cependant, notons que les navigateurs Web stockent l’historique des écrans en mémoire dans l’ordre d’apparition dans une pile FIFO afin de pouvoir les rappeler sans solliciter le serveur lors des retours arrière alors que les écrans IBMi sont persistants, donc pilotés à 100% par le programme côté serveur. Cette différence entre le client léger IBMi et le client léger Web présente des avantages et des inconvénients selon que les traitements sont persistants ou non persistants, l’informatique de gestion étant souvent persistante par nature.

-) intégration matériel/logiciel :

Oracle a acheté la société Sun et récemment Google la société Motorola afin d’intégrer en une seule entité le logiciel et le matériel afin de délivrer aux clients des produits finis clés en main. Avec l’intégration matériel/logiciel, le matériel devient de la matière première - commodity - nous disent Oracle et Google. Cette intégration étroite matériel/logiciel autorise des bonds technologiques importants sans toucher aux programmes. Ainsi, les programmes RPG ou COBOL développés dans les années 80-90 sont passés des processeurs CISC au RISC 64 bits puis à la gamme POWER multi-core sans même devoir recompiler les programmes (si l’observabilité des programmes n’avait pas été volontairement supprimée).

-) multi-tenant :

Le multi-tenant préconise une seule version de chaque programme en production, partagée par tous les utilisateurs. Si ce programme fait l’objet d’une modification, elle s’applique instantanément dès que ce programme modifié est mis en production. Notons que l’AS/400 et avant lui le S/38 étaient multi-tenant par nature, autrement dit le multi-tenant est pris intégralement en charge par le système d’exploitation. Google nous apprend que l’un des plus importants écueils du multi-tenant est son coût de développement très élevé. Cela nous donne une idée de l’avance considérable du S/38 et AS/400 qui géraient le multi-tenant automatiquement au niveau des couches basses de l’OS.

Concrètement, que faut-il faire pour être multi-tenant sur IBMi? Il suffit de compiler le programme et de l’appeler. L’operating system s’occupe de tout car  l’IBMi est multi-tenant et persistant par nature.

Voici ce qui nous dit Google à propos du multi-tenant :  « With muti-tenancy, multiple client can run the same application, segregating data using a unique namespace for each client » Sur AS/400 puis IBMi l’équivalent du « unique namespace » dont parle Google est la session identifiée de façon unique par un numéro de travail (la session est un job), ce qui permet une gestion multi-tenant native que nous appelons gestion multi-utilisateurs dans notre jargon IBMi.

L’ IBMi fait du multi-tenant comme Monsieur Jourdain faisait de la prose. Or le multi-tenant est considéré comme étant la pierre angulaire du Cloud Computing, un must. En effet, par définition même, il ne peut pas y avoir de Cloud Computing lorsqu’un programme est dupliqué autant de fois qu’il y a d’utilisateurs, comme c’est le cas pour le PCs/serveur lourd.

Le multi-tenant s’applique aussi bien pour les programmes que pour les données. Ainsi, lorsqu’une seule version d’une base de données est partagée en mémoire pour tous les utilisateurs elle peut être qualifiée de base de données relationnelle multi-tenant. A contrario, le va-et-vient des fichiers  du PCs/Serveur lourd est délirant. Sur IBMi tous les utilisateurs se comportent comme un seul utilisateur par une division des travaux en tâches élémentaires effectuée au niveau des couches basses de l’OS, d’où un partage multi-tenant natif qui n’a *rien à voir* avec le trafic des fichiers sur le réseau. Un informaticien nous disait qu’il est aussi risqué de modifier les systèmes de type PCs/Serveur lourd en fonctionnement que de vouloir réparer les ailes d’un avion en plein vol avec les passagers dedans. 

A la lumière de ces concepts novateurs énoncés par Google et Oracle pour les systèmes d’information du futur à savoir : le client léger, l’intégration matériel/logiciel et le multi-tenant, nous pouvons dire que le S/38 et l’AS/400 étaient des machines « extraterrestres » en leur temps. Dit clairement, le futur ne sera pas l’héritier du modèle PCs/Serveur lourd à complexité exponentielle, mais plutôt dans la lignée de l’IBMi avec les adaptations nécessaires au Cloud Computing afin de répondre à une nouvelle exigence en termes de disponibilité : partout, tout le temps, avec tout (Anywhere, Anytime, Anydevice).

Jean Mikhaleff/RePeGlio
 



 


Audience Xiti du site (stats)
reserved