Introduction    ▶    All as Definition


Du « Low Code » pour la définition d’Application
et par composition pour « Platform as Code » et « Infrastructure as Code »
afin que tout soit à la portée de tous les acteurs de l’IT


Description d'application

  • Une « Application » est typée (cf. « Application Type »), suivant son niveau d'implémentation :
    • ✓  « INTR » : Interaction Layer,
    ✓  « INTG » : Integration Layer (Exchange),
    ✓  « PROC » : Processing Layer,
    ✓  « COMP » : Computing Layer,
    ✓  « MGNT » : Management Layer;
  • et s'exécute suivant un pattern logique défini par un mode (cf. « Execution Mode ») :
    • ✓  « CMD » : Application composée de séquence de commandes,
    ✓  « WEB » : Application orientée Web (client léger),
    ✓  « DSK » : Application orientée Desktop (client lourd),
    ✓  « STR » : Application orientée Streaming,
    ✓  « BAT » : Application orientée Batch Contrôlé (phasing : PREPARE, PROCESS, COMMIT, ROLLBACK, CONFIRM) ,
    ✓  « SVC » : Application orientée Service,
    ✓  ...
  • Elle peut embarquer ou utiliser des modèles de données (cf. « Model Definition ») et des modules logiques (cf. « Module Definition »). Ainsi vos applications peuvent partager les mêmes logiques en Web, en desktop, en streaming, en batch ou en ligne de commande.

  • Elle peut référencer des ressources (cf. « Resource Definition ») telles que fichier, file de message ou stockage de données (structurées ou non structurées).

  • Les ressources peuvent être fournies par des technologies (cf. « Provider Definition ») en utilisant des librairies externes (cf. LIB).

  • La sécurité (identification, authentification, habilitation et audit) peut être définie comme une sorte d'aspect (cf. AOP) sur chaque module.

    • Description de platforme


  • Une plateforme applicative est constituée d’applications (cf. « Application Definition ») qui bénéficient les ressources (cf. « Resource Definition »), les capacités logiques et les logiciels offerts par la plateforme

  • Si la plateforme prend en charge des solutions logicielles ou d’autres applications spécifiques (cf. « Software Definition »), elle peut référencer des binaires (cf. BIN) de la solution.

  • Une plateforme doit définir sa topologie de déploiement et d'exécution (cf. « Environnement Definition »).



    • La plateforme peut fournir les ressources aux applications qu'elle heberge :
  • « FILE » pour les ressources sous forme de fichier et qui sont stockées dans un « File System » en tant que « File Location ». Le flux de lecture est sous forme de « Input Stream ». Le flux d'écriture est sous forme de « Output Stream ». Le contenu d'un fichier se matérialise par des lignes d'information « LINE » ou « ROW ».
  • « MESSAGE » pour les flux asynchrones et qui sont stockés ou acheminés par un « Message Broker ». Comme un message a pour vocation d’aller vers une ou plusieurs destinations « Message Destination », il doit y avoir un émetteur « Message Sender » et un récepteur/lecteur « Message Receiver » ou un service d'écoute « Message Listener ».
  • « DATA » pour les données stockées dans un « Data Store ou Data Space » fourni par un « Data Storage ». Les données peuvent être accédées unitairement en mode CRUD ou en masse en utilisant les ordres DML et DQL. Les données sont représentées par des lignes d’information « ROW ».

  • En tant qu'aspect, la sécurité peut être définie sur chaque ressource (Resource), solution (Software) et environnement (Environment).

    • Description de l'infrastructure

    L'infrastructure est définie principalement par les éléments suivants :
  • Le point d’entrée d'un environnement (cf. « Environment Definition ») vers l'infrastructure est l’unité d’hébergement ou le composant d’hébergement dit « HOST » (cf. « Host Definition ») avec la description de son système d'exploitation/exécution/opération (cf. « System Definition »).
  • Le « HOST » est au final associé à un matériel (cf. « Hardware Definition ») et accessible au réseau (cf. « Network Definition »). Le matériel peut fournir un ou plusieurs « HOST » et un ou plusieurs réseaux, et qui peut être un matériel ou équipement réseau.
  • Afin de rationaliser ou cloisonner les ressources, il se peut que l’on fasse recours à la virtualisation (cf. « Virtualization Definition »). La virtualisation peut être fournie par un logiciel (cf. « Software Definition ») ou intégrée au matériel comme les « HARDWARE HYPERVISOR ». 


  • L’infrastructure assure la fourniture des ressources matérielles nécessaires à l'exécution des composants de la plateforme. Chaque matériel peut fournir les capacités et les ressources suivantes :
    • ✓  Les capacités de calcul, d'évaluation et de traitement : « CPU (Central) », « FPU (Floating Point) », « GPU (Graphic) », « SPU (Service, System and Security) », « APU (Audio, Acceleration) » et « TPU (Tensor : Matrix, Array),
    ✓  Les mémoires nécessaires aux différents traitement : « RAM », « MCU »,
    ✓  Les disques pour le stockage des données : « HDD », « SSD », …
    ✓  Et les interfaces réseaux pour la communication au sein de l'infrastructure : « NIC ». 
  • Chaque matériel peut être spécialisé à fournir seulement un ou quelques types de ressource :
    • ✓  « COMPUTE HARDWARE » pour les serveurs d’exécution classique,
    ✓  « NETWORK HARDWARE » pour les équipements dédiés aux réseaux,
    ✓  « STORAGE HARDWARE » pour les équipements dédiés aux stockages de données.



  • En tant qu'aspect, la sécurité peut être définie sur chaque élément de l'infrastructure (Hardware, System et Network).

    • Parfois on peut avoir un matériel tout en un, dit « MAIN HARDWARE ». Ce type de matériel peut porter en lui tout seul un besoin d'infrastructure.

    Comme nous venons de voir avec le matériel tout en un, l'infrastructure peut être portée par un seul gros matériel.
    Et on peut envisager que l'infrastructure peut être représentées de manière modulaire et hiérarchique :
    ✓  un « RACK »,
    ✓  une salle machine « ROOM »,
    ✓  un étage/niveau « FLOOR »,
    ✓  un bâtiment « BUILDING » et un « DATA CENTER ».
    Cette hiérarchie de l’infrastructure peut aller plus loin avec plusieurs « DATA CENTER » repartis
    ✓  dans un pays « COUNTRY »,
    ✓  ou « CONTINENT »,
    ✓  et voire même au niveau mondial « WORLD ».
    Cette hiérarchie qui s’applique au niveau de l’infrastructure affecte aussi le maillage du réseau.

    « The Network is the Computer »

    "do:IT" est compatible avec les composants à faible consommation de ressources, tels que Raspberry Pi.
    Projection de la plateforme sur l'infrastructure
    Avec la hiérarchie de l’infrastructure, les plateformes applicatives doivent se retrouver au dessus.

    Il est tout à fait envisageable à ce qu'une plateforme applicative soit repartie sur plusieurs infrastructures.
    Comme indiqué par ce schéma, la liaison entre la plateforme applicative et l'infrastructure d'hébergement est assurée par la définition « cf. Environment Definition » car celle-ci décrit la topologie de déploiement des composants applicatifs et logiciels de la « PLATFORM » vers « l’INFRASTRUCTURE ».


    C'est avec la définition « Environnement Definition » que l'on peut indiquer
    ✓  si un composant est en instance unique « Single Instance »
    ✓  ou en « Active / Passive » ou « Active / Standby ».

    Il est possible de préciser les besoins en ressources des composants suivant l’environnement cible.

    En tant qu'aspect, la sécurité peut être définie globalement au niveau de la plateforme mais peut être spécifique par type d'environnement
    On peut considérer 2 modes de projection de l’environnement :

  • Le mode « DEDICATED ENVIRONMENT » où l’infrastructure est dédiée à l’environnement, par abus de langage on peut dit « PHYSICAL ENVIRONMENT ». Ce mode est assez souvent appliqué pour l'environnement de « PRODUCTION (PROD) »,

  • Le mode « SHARED / MUTUALIZED ENVIRONMENT » ou l'infrastructure est mutualisée par plusieurs environnements, par abus de langage on peut dit « LOGICAL ENVIRONMENT ». Ce mode est assez souvent appliqué pour les environnements « HORS PRODUCTION » peu consommateurs en ressources, comme « DEVELOPEMENT (DEV) » et « INTEGRATION (INT) » ou « QUALIFICATION (QLF) ».
    • Virtualisation de l'infrastructure
  • L’approche de rationalisation nous amène à ne pas gaspiller les ressources.

  • Ce type de déploiement peut avoir rapidement de limite :
    • ✓  Si l’on souhaite cloisonner les composants applicatifs et logiciels, leur répartition sur plusieurs « HOST » serait un gaspillage ;
    ✓  De nos jours, on ne peut plus trouver des serveurs à faible capacité, ce qui fait que l’usage d'un matériel de grande capacité serait aussi un gaspillage ;
    ✓  Si l’on doit avoir plusieurs « HOST », est-ce que cela veut dire que l’on doit avoir plusieurs matériels.
    Ainsi la virtualisation des ressources est nécessaire : « VIRTUAL LAYER ».
  • La virtualisation des « HOST » est fournie par les « HYPERVISOR »
    et qui peut être faite au niveau matériel « NATIVE ou BARE METAL ou HARDWARE » ou au niveau de l’OS du matériel « HOSTED ».

  • Les « HOSTED HYPERVISOR » sont plus faciles à adopter car ils n'ont pas besoin de spécificités matérielles. Les « HOSTED HYPERVISOR » peuvent être classés en 2 catégories :
    ✓  Les machines virtuelles, « VIRTUAL MACHINE », ex : « VirtualPC » de Microsoft, « VirtualBox » d'Oracle, « VMware Workstation et Fusion » et « QEMU » ainsi que le Wrapper « Vagrant »
    ✓  Les systèmes de partitionnement de système, « OS-LEVEL VIRTUALIZATION », ex : « Xen » de Citrix, « OpenVZ », « Solaris Containers », « vSphere » de VMware, « Hyper-V » de Microsoft, « KVM » et « Oracle VM » qui est basé sur Xen.

  • Les « NATIVE ou BARE METAL ou HARDWARE HYPERVISOR » peuvent n’être que sur des matériels spécifiques, ex :
    ✓  « IBM LPAR »,
    ✓  « SUN LDOM »,
    ✓  et « HP Superdom ».

    • Isolation de l'espace d'exécution
    Le noyau de certains systèmes d’exploitation dispose de mécanisme de cloisonnement ou d’isolement de l’espace d’exécution d’un composant applicatif ou logiciel, dit « CONTAINER ENGINE »,
    ex :
    ✓  le « chroot » Unix,
    ✓  le prison BSD « BSD Jail »,
    ✓  les conteneurs d’exécution Linux « LXC » qui est la base de « Docker »,
    ✓  les librairies « libvirt »,
    ✓  les « systemd » avec Linux et « systemd-nspawn » avec Solaris d’Oracle.
    Les « CONTAINER » permettent de rationaliser davantage les ressources mais suivant la maturité des solutions et des systèmes, les fuites de ressources peuvent apparaître.

    Pour l'expansion des instances, les « CONTAINER MANAGER » offre les capacités de « scalabilité horizontale » des « CONTAINER ENGINE »,
    ex :
    ✓  « Kubernetes »,
    ✓  « Nomad de HashiCorp »,
    ✓  « Nutanix ».


    L’usage des systèmes distribués nous amène à une autre technique de cloisonnement et de gestion des ressources, les « RESOURCE MANAGER »,
    ex :
    ✓  « YARN » avec ou sans Hadoop,
    ✓  « Mesos ».
    Les « RESOURCE MANAGER » peuvent être limités sur leur capacité de gestion des ressources, ex :
    ✓  « YARN » est seulement pour les applications Java.