• Aucun résultat trouvé

Présentation de la solution Bridge-ITOPS

N/A
N/A
Protected

Academic year: 2021

Partager "Présentation de la solution Bridge-ITOPS"

Copied!
23
0
0

Texte intégral

(1)

HAL Id: hal-03201435

https://hal.archives-ouvertes.fr/hal-03201435

Submitted on 18 Apr 2021

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Présentation de la solution Bridge-ITOPS

Walid Saad, Christophe Cérin

To cite this version:

Walid Saad, Christophe Cérin. Présentation de la solution Bridge-ITOPS. [Rapport Technique] Uni-versité paris 13. 2021. �hal-03201435�

(2)

Présentation de la solution Bridge-ITOPS

Walid Saad et Christophe Cérin http://bridge-itops.com

12 avril 2021

Résumé

Ce rapport technique introduit le projet Bridge-ITOPS, une solution généraliste à base de technologie Cloud et DevOps, qui facilite la transformation numérique des organisations. Il s’agit de faire en sorte que l’informatique du XXIème siècle puisse être accessible à tous et percoler au plus près des utilisateurs avec une intervention minimale des experts du domaine, selon un mode à la demande et en un clic souris. Le rapport technique est organisé en deux grandes parties. La première partie expose les motivations, les visions et les missions prises en compte dans le projet Bridge-ITOPS. La seconde partie introduit les fonctionnalités des principaux composants logiciels de la solution en détaillant le mode graphique puis le mode expert d’utilisation de l’outil. Nous donnons également, à la fin du document, quelques repères bibliographiques concernant les technologies sur lesquelles s’appuie le projet Bridge-IOTPS.

1

Introduction

1.1 Motivations et objectifs

Bridge-ITOPS est un projet qui a vocation à répondre aux besoins de transformation numérique (IT - Information Technology) des organisations privées ou publiques, petites ou grandes, en utilisant les technologies de l’informatique nuagique (Cloud) et la culture DevOps. Ce projet permet à toutes ces organisations de déployer rapidement des écosystèmes numériques complets. À titre d’exemples, il est possible de déployer :

1. Une chaîne d’outils DevOps pour les projets de développement logiciels tels que les applications de bureau, les sites Web, les applications mobiles, etc.

2. Une chaîne d’outils DevOps pour les applications IoT (Internet des Objets) dans le cadre des projets Edge Computing, la technologie incontournable de l’industrie 4.0 (par exemple les applications Smart Home, Smart Cities et Smart Cars). 3. Une chaîne d’outils DataOps pour les applications Big Data, IA (Intelligence

Artificielle) et ML (Machine Learning). Nous rappelons que le DataOps est le DevOps appliqué aux projets de la science des données (Data Science).

Ce document est mis à disposition selon les termes de la licence Creative Commons “Attribution – Pas d’utilisation commerciale – Partage dans les mêmes conditions 4.0 International”.

(3)

Le déploiement de l’écosystème se réalise sans intervention d’un informaticien. Il est automatisé et il est à la portée d’un non spécialiste du domaine numérique. Les organisations peuvent alors se concentrer exclusivement sur la solution à apporter aux projets sans avoir à gaspiller du temps sur les questions d’accès et de partage d’une infrastructure numérique. Bridge-ITOPS n’est pas qu’une solution technique autour du Cloud et du DevOps. C’est aussi une solution intégrée pour organiser des équipes et des projets. Bridge-ITOPS a donc aussi une dimension Ressources Humaines (RH). Avant de continuer, rappelons que le Cloud correspond à l’accès à des services informatiques partagés configurables (serveurs, stockage, mise en réseau, logiciels) via Internet, à la demande et en libre-service. Il s’agit donc d’une délocalisation de l’infrastructure informatique qui se retrouve chez un fournisseur. Les fournisseurs de Cloud publics les plus connus sont Google, Amazon, Microsoft mais aussi Alibaba et Huawei. L’utilisateur final passe par son navigateur pour accéder aux ressources et il n’a plus à gérer manuellement l’installation des logiciels. Son poste de travail est délocalisé dans le nuage et l’installation est automatisée.

Par ailleurs, rappelons également que le sigle DevOps est la concaténation des trois premières lettres du mot anglaisdevelopment (développement) et de l’abréviation usuelle ops du mot anglais operations (exploitation), deux fonctions de la gestion des systèmes informatiques qui ont souvent des objectifs contradictoires. Le DevOps vise à raccourcir le cycle de vie du développement des systèmes informatiques et à assurer une livraison continue avec une haute qualité logicielle, précisément en rapprochant les cycles de développement et de déploiement opérationnel. La culture DevOps est complémentaire du développement logiciel Agile ; plusieurs aspects du DevOps proviennent de la méthodologie Agile.

Les technologies de Cloud et DevOps permettent de mettre en place des usines logicielles généralistes autorisant à développer des solutions pour des marchés multiples et variés. Pour prendre une analogie, dans le secteur de la construction automobile, une même plate-forme (structure de base d’un véhicule) permet la construction de modèles différents d’automobiles. De même, la conception et la production des moteurs sont soumises aux mêmes règles industrielles et sont souvent produites en commun. Ils servent à la motorisation de multiples modèles d’automobiles avec des annexes et des réglages différents. Il s’agit de démarches de conception modulaire qui sont particulièrement intéressantes lorsqu’il s’agit de créer des variantes d’un produit. Bridge-ITOPS veut suivre ces principes généraux et capitaliser sur le Cloud et le DevOps.

1.2 Le problème typique d’une organisation en matière numérique

Pour illustrer ce que nous venons d’exposer concernant les objectifs de Bridge-ITOPS, prenons maintenant le cas des Startups. En règle générale, ces organisations ne sont pas organisées pour avoir des équipes expertes dans les domaines du Cloud et du DevOps. Cependant, l’adage selon lequel « toute Startup est une Startup technologique » est reconnu comme étant particulièrement pertinent. De fait, toute Startup, quel que soit son secteur d’activité ou sa taille, a une dimension axée sur les technologies numériques (IT) et dépend d’elle. De nos jours, la compétitivité d’une Startup dépend directement de sa capacité à :

— Innover et à développer rapidement de nouvelles idées ;

— Moderniser son infrastructure IT pour devenir plus productive, efficace, agile et compétitive ;

(4)

— Exploiter les avantages du Cloud et de la culture DevOps pour renforcer la flexibilité et l’évolutivité de l’offre ;

— Gérer le coût d’investissement IT en termes de temps et d’argent.

Il est clair que la transformation IT des Startups demande nécessairement un investissement dans les technologies Cloud et DevOps. Cet investissement en IT va permettre de moderniser les infrastructures IT d’une part, et d’autre part, de recruter de nouvelles compétences, plus expérimentées en matière de Cloud/DevOps. Mais, cela n’est pas toujours souhaité par une Startup, par manque de moyens, d’expertise ou de temps, préférant concentrer les moyens sur le cœur de son secteur d’activité. Cependant, à la suite de la crise sanitaire COVID-19, il paraît urgent de donner un coup d’accélérateur à la transformation IT des Startups en leur permettant d’accéder aux services numériques dont elles ont besoin, à travers un navigateur et selon des processus de déploiement, de configuration et de provisionnement automatisés.

Leurs défis consistent alors à accélérer le processus de transformation numérique sans trop avoir à investir dans l’IT tout en préservant les activités métier de la Startup.

1.3 Autres cas d’usage

Bridge-ITOPS s’avère être une solution adéquate dans de nombreux secteurs d’activité. Pour le mesurer, nous détaillons maintenant trois cas d’usage dans trois secteurs d’activité différents. Ces trois cas d’usage sont relatifs au contexte universitaire qui est un contexte que nous connaissons bien puisque les concepteurs de la solution Bridge ITOPS sont issus du milieu universitaire. Cependant, nous savons bien que le défi de la transformation numérique au sein des universités est un immense défi qui ne relève pas seulement de défis techniques, mais aussi de défis politiques, parfois idéologiques, et avant toute chose de défis culturels liés au changement.

Cas d’usage numéro 1 : le COVID-19 a eu un effet dévastateur dans le monde entier, forçant des changements profonds dans la plupart des interactions humaines et en particulier dans les interactions entre le professeur et l’étudiant. La manière dont se passe la diffusion en ligne de matériel éducatif présente de nombreux défis. Ils sont tous dépendant du numérique. D’un point de vue technologique, il s’agit de pouvoir déployer une plate-forme pédagogique, adaptée aux besoins de chaque enseignant, donc hautement configurable et à la demande. Cette plate-forme doit offrir non seulement des contenus et des activités, comme Moodle (https ://moodle.org/) peut le faire, mais aussi des outils pour expérimenter, pour rejouer des scénarios selon différentes hypothèses. Pour cette dernière considération, des solutions comme RosettaHub (https ://rosettahub.com/) ou Strigo (https ://strigo.io/) peuvent aider. Cependant, Bridge-ITOPS a le potentiel de pouvoir déployer simultanément tous ces différents outils afin de produire une plate-forme d’apprentissage unifiée. De plus, Bridge-ITOPS permet aussi de déployer ces environnements dans un Cloud privé (celui de l’université) et pas forcément dans des Clouds publics pour lesquels la communauté éducative souhaite assez souvent se détacher.

Cas d’usage numéro 2 : pour les problèmes de grandes masses de données, Cluster4ever (https://github.com/Clustering4Ever/Clustering4Ever) est une bibliothèque de regroupement de données (clustering) rassemblant des algorithmes non supervisés et des indices de qualité. Elle est développée à l’université Sorbonne Paris Nord par un groupe d’experts du domaine. Un pipeline de données englobe une série d’actions qui débute avec l’ingestion de l’ensemble des données brutes issues de n’importe quelle source, pour les transformer rapidement en données prêtes à

(5)

être exploitées. L’exploitation peut être le regroupement, façon Cluster4ever. Le post-traitement peut consister à de la visualisation des résultats ou à un archivage. À chacune de ces étapes correspond un outil. Bridge-ITOPS a le potentiel d’offrir le déploiement coordonné de chacun des étages du pipeline avec la possibilité supplémentaire de déployer l’ensemble du pipeline dans un Cloud public. L’avantage de Bridge-ITOPS est ici de pouvoir déployer automatiquement tout un écosystème de gestion de données massives, et pas seulement un seul composant.

Cas d’usage numéro 3 : 3Dmap (https://www.3dmap.fr/) est une startup qui est entrée dans l’incubateur de l’université Sorbonne Paris Nord, Incub’13, en 2016. 3Dmap réalise des cartes en relief qui sont thermomoulées. Avant le moulage il y a une étape de modélisation de la carte, par l’intermédiaire de la résolution d’équations propres à 3Dmap. Il s’agit ici de calcul scientifique afin de produire des coordonnées (x, y, z) pour le plan en relief. Nous pouvons ici imaginer que Bridge ITOPS déploie automatiquement et à la volée, un cluster de calcul afin de lancer en parallèle plusieurs simulations numériques ce qui permettrait à 3Dmap de réduire son temps de mise sur le marché des cartes en relief. De manière plus générale Bridge-ITOPS pourrait faire partie du portefeuille de services offerts par les incubateurs des universités afin que les incubés puissent rapidement avoir un environnement numérique de travail adapté à leur activité.

1.4 Précisions sur la solution Bridge-ITOPS vis à vis des publics auxquels nous rendons service

Afin d’accélérer et de réussir sa transformation IT, une Startup devrait se mettre à l’heure du Cloud natif. Il s’agit d’un nouveau modèle organisationnel propre à l’informatique qui permet aux organisations de développer des applications hautement scalables i.e. qui continuent de bien fonctionner quand la charge varie de manière brutale, résilientes et déployables dans divers environnements Cloud. Désormais, elles ont besoin de disposer d’une plate-forme de développement logiciel de bout en bout, capable d’automatiser et d’intégrer les nouveaux concepts de l’IT moderne comme le DevOps et les technologies des conteneurs, en passant par l’intégration et le déploiement continu et l’architecture en micro-services.

C’est dans cette optique que Bridge-ITOPS propose une solution de passerelle vers le Cloud natif. Bridge ITOPS est donc une plate-forme de gestion des services DevOps et des infrastructures Cloud, en anglais nous pouvons parler deDevOps and Cloud Management Platform (DCMP). Bridge-ITOPS a pour objectif principal de fournir aux organisations les outils et l’accompagnement nécessaire afin de :

— Réussir leur parcours de transformation IT et atteindre leurs objectifs commerciaux

— Minimiser les coûts d’investissement en IT en termes du temps et de l’argent

Le site Web du projet est le suivant : http://bridge-itops.com

1.5 Le composant principal de la solution Bridge-ITOPS

Bridge-ITOPS, à travers le composant Bridge LABS, met à disposition des organisations une plate-forme prête pour le Cloud (Cloud natif ), permettant aux organisations de se concentrer sur le cœur de leurs métiers et d’aller rapidement sur les deux aspects d’innovation et de livraison

(6)

logicielle. Cette plate-forme va permettre aux organisations de moderniser leurs applications et infrastructures IT en transformant leur processus classique de livraison d’applications afin d’aller vers une nouvelle organisation de livraison d’applications plus agile, flexible et automatisée. Cela se réalise uniquement si l’on peut compter sur des équipes inter-fonctionnelles intégrées et qui communiquent entre elles.

Contrairement aux plate-forme existantes, Bridge LABS vise essentiellement à offrir, à travers une stratégie multi-cloud, des services d’automatisation open source afin de profiter le plus rapidement possible d’un environnement DevOps-ready et de bénéficier de tous les avantages du modèle Cloud-natif et les bonnes pratiques de la culture DevOps.

1.6 Le marché Cloud et DevOps - Contexte académique et professionnel

1.6.1 Contexte académique

Pour parler des solutions directement issues de propositions académiques couplées à des projets européens où au delà de l’Europe, donc à des projets R&D, nous voudrions mentionner le portail EOSC2qui permet un accès facile à de nombreuses ressources pour divers domaines de recherche ainsi qu’à des outils intégrés d’analyse des données. Le portail de l’EOSC est une passerelle vers les informations et les ressources de l’EOSC, fournissant des mises à jour sur sa gouvernance et ses acteurs, les projets contribuant à sa réalisation, les opportunités de financement pour les parties prenantes de l’EOSC, les politiques européennes et nationales pertinentes, les documents importants et les développements récents.

À partir de ce portail, l’utilisateur peut naviguer par domaine scientifique, catégorie de ressources ou fournisseur. À partir de ce site, les projets qui ressemblent, par certains côtés, le plus à Bridge-ITOPS sont mentionnés aux Tableaux 1 et 2. Nous inclusons également, dans ces Tableaux, les facteurs différenciants.

1.6.2 Contexte professionnel

Dans un contexte purement professionnel, plusieurs solutions existent sur le marché (open source ou sous Licence) qui permettent de faciliter le déploiement des infrastructures conteneurisées en mode CaaS (Container as a Service) et de fournir du service DevOps en mode PaaS. Chaque solution répond à des besoins spécifiques. On trouve par exemple des solutions comme VMWare Tanzu, Openshift, Rancher RKE, Jelastic (https://jelastic.com/) et d’autres solutions, comme Rancher K3s, qui répondent mieux aux cas d’usage IoT, CI (Continuous Integration) ou qui captent les architectures de processeurs ARM. Nous commentons maintenant quelques solutions dans le Tableau 3.

(7)

Table 1: Quelques projets développés dans des projets européens (1/2)

Nom projet Description générale Facteurs différenciants Nuvla3 Solution multi-cloud, hybrid-cloud et plate-forme

de gestion de périphérie (Edge) capable de s’interfacer avec de nombreux fournisseurs et solutions de Cloud Computing. Elle automatise le cycle de vie complet de la gestion, y compris le déploiement, le test, la certification et l’optimisation des applications au sein des infrastructures de Cloud et de Edge. Les organisations utilisant Nuvla bénéficient des caractéristiques suivantes :

1. Gouvernance : contrôle de tous les aspects du déploiement des applications, de l’accès et de la gestion des données, y compris l’audit.

2. Contrôle des applications : à partir de n’importe quel dépôt de conteneurs privé ou public, vous pouvez configurer, déployer, surveiller et mettre à jour les applications de manière sécurisée, y compris les fonctionnalités avancées telles que l’analyse comparative et la politique de placement des applications.

3. Gestion des données : les données produites en périphérie ou dans le nuage sont gérées, y compris le marquage, la réplication et le transfert des données, ainsi que la recherche et l’accès aux données. Cette fonctionnalité fonctionne également en mode semi-connecté, de sorte qu’en cas de perte de connexion, le transfert ou la réplication des données reprend une fois la connexion rétablie ; 4. Contrôle de sécurité : permet des contrôles

de sécurité de bout en bout, de la périphérie au nuage, et inversement, en utilisant la technologie de VPN, la gestion des identités et des accès, ainsi que l’application de l’intégrité.

5. Contrôle de périphérie : permet de gérer les dispositifs de périphérie, notamment l’enregistrement sécurisé, la mise à jour, ainsi que la surveillance et les notifications.

Les principales technologies sont Docker Swarm, Elasticsearch, Zookeeper, Prometheus, Traefik, MinIO, et une technologie de micro-services. La technologie de déploiement est Maven. Apache Maven est un outil de gestion et de compréhension de projets logiciels. Il est basé sur le concept d’un modèle objet de projet (POM), Maven peut gérer la construction, le reporting et la documentation d’un projet à partir d’une information centrale.

Par rapport à Nuvla, Bridge LABS est une plate-forme multi-cloud permettant d’offrir un environnement de gestion et de développement clés-en-main destiné aux différents types de projets de l’IT y compris le Edge Computing. Un autre avantage important de Bridge LABS est sa capacité d’automatiser tout le processus DevOps, commençant par la création de l’infrastructure Cloud jusqu’au déploiement des pipelines d’intégration et de livraison continue. D’où, sa capacité d’offrir une abstraction totale des opérations complexes et de réduire les obstacles qui se dressent devant la réussite de la Transformation IT des entreprises .

Comme Nuvla, Bridge-ITOPS peut être déployée en micro-services :

1. Un service Frontend : offre un tableau de bord accessible par les différentes équipes de l’IT.

2. Un service Backend : offre le Core API de Bridge LABS.

3. Un service DataBase qui sert à stocker l’état de la plate-forme.

(8)

Table 2: Quelques projets développés dans des projets européens (2/2)

Nom projet Description générale Facteurs différenciants PaaS

Orchestrator4

L’orchestrateur permet de coordonner l’approvisionnement en ressources de calcul et de stockage, virtualisées sur du Cloud, tant privés que publics (comme OpenStack, OpenNebula, AWS, etc.), et le déploiement de services et de travaux par lots dockerisés de longue durée sur des clusters Apache Mesos.

L’orchestrateur reçoit les demandes de déploiement, exprimées par le biais de modèles écrits en TOSCA (Simple Profile in YAML version 1.0), et orchestre les déploiements sur les meilleurs sites de Cloud disponibles.

Afin de sélectionner le meilleur site, l’orchestrateur met en œuvre un workflow complexe : il recueille les informations sur les SLA signés par les fournisseurs avec l’utilisateur, les données de contrôle sur la disponibilité des services de calcul et de stockage, la localisation des données demandées par l’utilisateur (le cas échéant). Les déploiements hybrides s’étendant sur plusieurs sites sont pris en charge.

En utilisant l’orchestrateur PaaS et les modèles TOSCA, les utilisateurs finaux peuvent exploiter les ressources de calcul sans connaître les détails de l’infrastructure sous-jacente.

Les principales technologies du projet sont Docker, Ansible, Oasis Tosca, OpenStack, Apache Mesos et Infrastructure Management (IM). C’est ce dernier outil qui est le plus proche de Bridge-ITOPS. IM est un outil qui déploie des infrastructures virtuelles complexes et personnalisées sur de multiples back-ends.

IM automatise la sélection, le déploiement, la configuration, l’installation de logiciels, la surveillance et la mise à jour des infrastructures virtuelles. Il prend en charge une grande variété de back-ends, rendant ainsi les applications utilisateur agnostiques au Cloud.

En outre, il dispose de capacités DevOps, basées sur Ansible pour permettre l’installation et la configuration de toutes les applications nécessaires à l’utilisateur, lui fournissant ainsi une infrastructure pleinement fonctionnelle.

IM est un service qui comprend une interface graphique basée sur le Web, une API XML-RPC, une API REST et une interface en ligne de commande.

INDIGO est plutôt un broker en mode PaaS uniquement qui permet de déployer et orchestrer en multi-cloud une grande variété de services informatiques.

Bridge LABS s’inscrit dans la même logique d’abstraction des infrastructures Cloud, y compris les modèles de déploiements IaaS, le PaaS et le CaaS.

En particulier, l’API REST DevOps de Bridge LABS est un service PaaS qui permet d’automatiser le déploiement d’une plate-forme DevOps fonctionnelle selon les besoins de l’entreprise.

(9)

ePouta5 ePouta fournit :

1. Un calcul haute performance avec une flexibilité et une expérience utilisateur supérieures grâce à un mode infrastructure en tant que service (IaaS) 2. Vous pouvez déployer des ressources telles que des machines virtuelles, du stockage et du réseau, et en avoir le contrôle total

3. Variété de ressources : par exemple, machines virtuelles, dispositifs en bloc (block device), réseaux virtuels, adresses IP flottantes, calcul haute performance et GP U

Le service ePouta est conçu pour le traitement de données sensibles. Si vous n’avez pas de données sensibles, vous pouvez utiliser la variante cPouta. C’est une offre IaaS (Infrastructure as a Service) basée sur le logiciel open source OpenStack.

Le service permet d’exécuter vos propres machines virtuelles sur l’infrastructure mais aussi un contrôle total des applications et du système d’exploitation et enfin une connexion directe à Internet, offrant de nouvelles possibilités de collaboration. Le service de Cloud computing cPouta est destiné à tous les domaines scientifiques.

Les projets de recherche qui nécessitent des piles d’applications complexes ou des applications avec une interface utilisateur basée sur un navigateur sont des exemples de domaines dans lesquels le service cPouta est particulièrement adapté.

ePouta offre un service IaaS qui ressemble à Amazon EC2 par certains côtés comme la gestion directe par l’utilisateur de groupes de sécurité, des volumes de disques. . . Il n’y a pas de technologie Cloud Native à l’intérieur du projet (comme le DevOps et les conteneurs).

Bridge-ITOPS permet aux utilisateurs de créer des machines virtuelles sur un Cloud OpenStack et de déployer par la suite un cluster Kubernetes avec des services DevOps préconfigurés.

4. https ://indigo-paas.cloud.ba.infn.it/ 5. https ://research.csc.fi/-/epouta

(10)

Table 3: Quelques projets développés dans l’industrie

Nom projet Description générale Facteurs différenciants VMWare Tanzu

Kubernetes Grid6

Projet créé par la société VMWare, Tanzu est un ensemble de solutions permettant d’orchestrer des clusters Kubernetes.

Il s’agit d’une distribution Kubernetes qui permet de provisionner des CaaS sur vSphere et en multi-cloud GCP AWS, Azure).

VMWare Tanzu Kubernetes Grid se présente sous la forme d’un binaire nommé tkg et il permet d’instancier les clusters en fonction de plan prédéfinis. Les clusters sont provisionnés à partir d’OVA basées sur Photon, le système d’exploitation développé par VMWare.

VMWare TKG est une solution destinée principalement aux SysOps qui a pour objectif la création et la gestion des Multi-CaaS dans les environnements VMWare et Cloud Provider.

Bridge LABS vise à offrir une plate-forme de gestion plus générique accessible par toutes les équipes IT (développeurs et opérateurs). Selon les besoins de l’entreprise, elle permet d’approvisionner des environnements Cloud (IaaS et CaaS), et du DevOps sur site (on-premises) et en mode SaaS (dans sa version Cloud-hosted). Redhat Openshift

PaaS7

OpenShift est un PaaS qui s’appuie sur Kubernetes et permet de construire, déployer et gérer des applications Cloud-native dans des conteneurs.

Avec cette plate-forme open source :

1. Les opérateurs mettent en place des clusters Kubernetes dans un environnement Redhat ou sur un Cloud Provider

2. Les développeurs peuvent créer, tester et exécuter leurs applications, puis les déployer dans leurs plate-formes.

OKD « Openshift Kubernetes Distribution » propose des fonctionnalités similaires à celles de Bridge LABS en mode graphique. Les principales différences sont que l’installation d’OKD est moins automatisée et qu’elle se limite uniquement à des fonctionnalités identifiées PaaS/CaaS. Par contre, Bridge LABS offre, entre autres choses, une solution IaaS en multi-cloud.

1.7 Les facteurs différenciants de la solution

Bridge LABS offre une plate-forme d’ingénierie basée sur une solution hybride qui combine à la fois trois modèles de services : IaaS, CaaS et DevOps as a service. Bridge LABS offre aussi une solution intégrée pour organiser des équipes et des projets permettant un accès centralisé et cross-fonctionnel en utilisant la même interface utilisateur (via une interface html-based ou bien une CLI).

La valeur ajoutée de Bridge LABS pour une organisation se résume dans les points suivants. Elle permet de :

6. https ://tanzu.vmware.com/ 7. https ://www.openshift.com/

(11)

— Se concentrer sur son cœur de métier sans trop investir dans le développement et la gestion de l’infrastructure IT (Support et Day-2) ;

— Sélectionner les outils DevOps qui répondent efficacement aux besoins stratégiques et de clientèles et les déployer en multi-cloud afin de garantir une meilleure expérience client et de gagner en compétitivité ;

— Garder le contrôle sur la plate-forme DevOps à travers un point de contrôle unique accessible par toutes les équipes IT ;

— Adopter une stratégie multi-cloud pour ne pas déléguer toutes les activités à un seul fournisseur de Cloud afin de garantir l’indépendance vis-à-vis des choix techniques (problèmes du « Cloud dépendance » et de « vendor lock-in ») ; — Passer à échelle en limitant l’augmentation des coûts de façon exponentielle en

cas de croissance des besoins ;

— Améliorer la productivité et l’autonomie des équipes (DevOps, Administrateur Système, Business & IT Leader) et la qualité des applications en appliquant le modèle opérationnel GitOps et les pratiques CI/CD (Intégration et Livraison Continue). Le GitOps est une approche qui permet aux équipes DevOps de décrire l’état de leur infrastructure dans un dépôt Git (c’est l’unique source de confiance).

— Optimiser la gestion des infrastructures IT en automatisant les processus manuels et complexes via des interfaces de programmation (API) de type Infrastructure as Code , ou IaC, ce qui va permettre de gagner en efficacité et en agilité. Nous rappelons que l’Infrastructure as Code est un type de configuration informatique permettant aux informaticiens de gérer et d’approvisionner automatiquement l’infrastructure informatique par le biais du code sans passer par des processus manuels.

1.8 Les deux modes de fonctionnement de Bridge-ITOPS

Bridge LABS permet d’automatiser la mise en place d’une Multi-cloud DevOps Platform Management (MDPM). Bridge LABS offre les deux modes de fonctionnement suivants :

— Un mode graphique (point-and-click). Il s’agit d’unpoint de contrôle unique (single point of management) d’une infrastructure DevOps-ready accessible par toutes les parties prenantes (cross-functional-teams) d’un projet informatique. Ce mode permet de gérer les infrastructures Cloud (IaaS), les clusters Kubernetes (CaaS), les services DevOps CI/CD et les équipes IT.

— Un mode expert destiné aux organisations qui privilégient le co-développement et qui adoptent le modèle opérationnel GitOps. Ce mode fournit duGitOps as a Service à travers un ensemble d’API Infrastructure as Code permettant de développer et d’automatiser le cycle de vie du développement logiciel, de bout en bout, en combinant la puissance des outils Git, CI/CD et Kubernetes.

Dans la suite du document nous présenterons en détail les deux modes de fonctionnement de Bridge LABS. Le discours que nous adoptons à partir de maintenant est clairement plus technique que ce qui précède. Une culture de haut niveau dans les technologies que nous mentionnons

(12)

est nécessaire à la bonne compréhension du texte. Le propos s’articule autour des différentes fonctionnalités du prototype logiciel existant à ce jour. Nous présentons plus particulièrement les interfaces de gestion de la plate-forme Bridge-ITOPS c’est-à-dire le mode d’administration plutôt que le mode d’utilisation des logiciels déployés.

2

Bridge LABS et le mode graphique

2.1 Services de base

Ce mode offre quatre services d’automatisation via une interface graphique HTML5-based :

— Le service IaaS permet de créer une infrastructure multi-cloud ;

— Le service CaaS permet de déployer un Cluster Kubernetes as a Service selon le besoin de l’organisation. Le CaaS peut être déployé en modefull-managed par le fournisseur Cloud (ex AKS, EKS) ou bien approvisionné en utilisant un serveur Rancher ;

— Le service DevOps toolchain permet à l’utilisateur de sélectionner un service ou bien une pile de services DevOps et les déployer directement sur le CaaS ; — Un service pour la gestion des utilisateurs, équipes et projets.

Bridge LABS utilise les technologies Cloud-Native : de l’infrastructure as Code au DevOps, en passant par les conteneurs Docker et les micro-services.

2.2 Fonctionnement de Bridge LABS

Le principe de l’interaction utilisateur avec Bridge LABS est illustré à la Figure 1. Le SysOps (ou bien le Platform Engineer) commence par mettre en place l’infrastructure DevOps en trois étapes : le provisionnement de l’infrastructure, l’installation des clusters Kubernetes et la mise en place de la plate-forme DevOps. Une fois que tout est mis en place, l’équipe DevOps peut à ce moment-là exploiter les outils DevOps dans leurs pipelines CI/CD applicatif.

2.3 Interfaces de Bridge Labs

Cette section présente les interfaces Web liées aux services de base de la solution pour la gestion des IaaS, CaaS, comptes Cloud, Utilisateurs & Équipes et Projets.

2.3.1 Multi-cloud IaaS

Comme le montre la Figure 2, la création d’une infrastructure multi-cloud se fait en quatre étapes, comme suit :

a. Sélectionner le fournisseur Cloud ; b. Sélectionner le compte Cloud ;

c. Spécifier la configuration de base de l’infrastructure que l’on veut créer. Il y a deux types de paramètres : ceux qui sont spécifiques au fournisseur Cloud (configuration physique, emplacement géographique, réseau et sécurité, compte

(13)

Figure 1 – Bridge LABS - Fonctionnement

utilisateur, etc) et ceux qui concernent le type de l’environnement (par exemple dev, test, prod, etc) et le nombre de machines virtuelles souhaitées.

d. Avant de lancer le déploiement de l’infrastructure, un résumé s’affiche à l’utilisateur lui demandant de valider tous les paramètres saisis.

Figure 2 – Bridge LABS - Menu IaaS

A la Figure 3, le menuIaaS/list permet de lister les informations IaaS déployées. Les informations affichées dans la capture d’écran concernent le cas d’une infrastructure Azure.

(14)

Figure 3 – Bridge LABS - Azure IaaS

2.3.2 Multi-CaaS

A la Figure 4, le menuCaaS/Hosted Kubernetes Cluster permet de créer un cluster Kubernetes totalement géré par un fournisseur de Cloud de type AKS, EKS ou GKE. Cependant, le menu CaaS/Rancher Kubernetes Cluster permet de déployer un cluster Kubernetes avec Rancher RKE sur une infrastructure IaaS créée au préalable à travers le menu IaaS.

Figure 4 – Bridge LABS - Kubernetes CaaS

A la Figure 5, un clic sur le menuCaaS/Cluster List permet d’afficher l’ensemble des informations relatives aux clusters Kubernetes déployés. A titre d’exemple nous trouvons le Endpoint, le fichier de configuration KubeConfig, etc. On peut également supprimer un cluster à partir de cette interface. La Figure 5 illustre une instance Kubernetes déployée sur Azure avec Rancher RKE.

(15)

Figure 5 – Bridge LABS - Rancher RKE dans Azure

2.3.3 DevOps Stack

La Figure 6 montre une liste non exhaustive de services DevOps qui peuvent être déployés via le tableau de bord (Dashboard) Bridge LABS. Les services sont classés par catégories (CI/CD, Dépôt de code source, Dépôt d’Artefact, Sécurité, Qualité de code, etc.). Afin de déployer un service DevOps, l’utilisateur commence par sélectionner le service, puis le cluster Kubernetes dans lequel ce service sera déployé. L’utilisateur peut accéder au service en cliquant sur l’URL (Endpoint) affichée dans la liste des services correctement déployés.

Figure 6 – Bridge LABS - Liste des services DevOps

Il est aussi possible de créer une pile logicielle DevOps à travers la technique Drag & Drop disponible dans le menuStacks/Create (voir Figure 7). L’utilisateur sélectionne alors l’ensemble des services dont il a besoin puis il choisit le cluster Kubernetes, et enfin il peut lancer le déploiement

(16)

de la pile DevOps.

Figure 7 – Bridge LABS - Créer une pile DevOps (Drap & Drop)

2.3.4 Cloud Accounts

Pour qu’il puisse approvisionner une infrastructure Cloud, l’utilisateur doit ajouter les paramètres d’accès à son compte Cloud. Les Figures 8 et 9 montrent le cas d’un compte Cloud Azure.

Figure 8 – Bridge LABS - Menu compte Cloud

2.3.5 User-Team Management

Bridge LABS offre un point de contrôle unique non seulement pour les ressources IT mais aussi pour les équipes et les utilisateurs qui leur sont attachés. On peut ajouter un utilisateur en lui affectant un ou plusieurs rôles et rattaché à une ou plusieurs équipes. On peut activer, désactiver, modifier ou bien supprimer un utilisateur (voir Figure 10). Une fois qu’un utilisateur est connecté

(17)

Figure 9 – Bridge LABS - Exemple d’un compte Cloud Azure

à la plate-forme, la gestion de rôle permet d’adapter automatiquement le tableau de bord selon le rôle de l’utilisateur.

Figure 10 – Bridge LABS - Gestion des utilisateurs

Concernant les équipes, l’utilisateur doit spécifier, pour chaque nouvelle équipe, un Utilisateur Leader (Chef d’équipe) comme le montre la Figure 11.

2.3.6 Project Management

Le menu Project (voir Figure 12) permet de créer une organisation logique qui met en relation les équipes et les ressources informatiques de l’entreprise (Clusters Kubernetes). Pour chaque nouveau projet à développer, le leader IT (en discutant avec le Platform Engineer) peut réserver un cluster Kubernetes ou bien une partie du cluster (un ou plusieurs namespaces, dans la terminologie

(18)

Figure 11 – Bridge LABS - Gestion des équipes IT

Kubernetes) selon les besoins demandés et les ressources disponibles.

Figure 12 – Bridge LABS - Gestion des projets

3

Bridge LABS et le mode expert (GitOps as a Service)

Le mode expert de Bridge LABS est destiné aux organisations qui privilégient le co-développement à travers une approche low-code et en adoptant le paradigme GitOps as a Service. Ce mode permet de mettre en place un premier pipeline CI/CD « Infrastructure » et un deuxième pipeline CI/CD « Applicatif ».

Ce mode offre principalement trois API d’automatisation Infrastructure as Code :

(19)

multi-cloud ;

2. Une API destinée au déploiement de la partie CaaS basée sur Kubernetes and Rancher ;

3. Une API permettant le déploiement des outils DevOps. Ce mode a deux principaux avantages :

— Appliquer les bonnes pratiques DevOps au sein des équipes par le fait que ce mode permet aux opérateurs Dev et Ops d’utiliser le même langage pour coder leurs applications et infrastructures de gestion, de Dev, de test et de production ; — Améliorer l’agilité des opérateurs opérationnels et des "Platform Teams" à travers

la mise en place d’un workflow GitOps.

La Figure 13 montre le fonctionnement de base de ce mode. On trouve deux types d’infrastructures :

1. Une infrastructure de gestion et de pilotage basée essentiellement sur un cluster Kubernetes (Rancher RKE) à partir duquel le SysOps (Platform Engineer) va gérer toutes les opérations GitOps liées à la mise en place et contrôler l’infrastructure DevOps Application Delivery (les instances Cloud, les clusters Kubernetes des différents environnements tels que les outils-CI/CD, dev, test prod, etc.

2. Une infrastructure Application Delivery qui va être utilisée par les équipes DevOps.

Figure 13 – Bridge LABS - Mode expert

4

Repères bibliographiques

Cette section présente quelques lectures complémentaires en liaison avec le projet Bridge-IOTPS. Les références proposées ne constituent en rien une liste exhaustive. Cependant elles illustrent et introduisent de manière fine les différents enjeux et technologies à l’intérieur du projet.

(20)

L’informatique en nuage, telle qu’elle a été in introduite par le National Institute of Science and Technology (NIST) dans [1] est un modèle permettant un accès réseau omniprésent, pratique et à la demande à un pool partagé de ressources informatiques configurables (par exemple, réseaux, serveurs, stockage, applications et services) qui peuvent être rapidement approvisionnées et libérées avec un minimum d’efforts de gestion ou d’interaction avec le fournisseur de services. Ce modèle est composé de cinq caractéristiques essentielles, de trois modèles de service et de quatre modèles de déploiement. Toutes ces termes sont précisés dans le rapport du NIST qui est donc une lecture fondamentale.

Les modèles économiques liés au Cloud Computing sont discutés dans [2, 3]. Dans l’étude [2], les auteurs, développent et simulent un modèle de tarification des ressources en nuage qui satisfait à deux contraintes importantes : la capacité dynamique du modèle à fournir une garantie de satisfaction élevée mesurée en termes de qualité de service (QoS) - du point de vue des utilisateurs - et des contraintes de rentabilité - du point de vue des fournisseurs de services en nuage. La référence [3] constitue une enquête et une synthèse de méthodes de tarification dans le Cloud. Les deux références [4, 5] font référence à des projets en éducation qui mettent en avant les technologies du Cloud Computing. L’étude de l’ALECSO [4] discute des stratégies d’adoption du Cloud pour l’enseignement. Le projet RosettaHub [5] est une solution effective pour utiliser les ressources de Google (GCP), Amazon (AWS) et Microsoft (AZURE) à des fins pédagogique. L’accès des étudiants aux Clouds publics pour apprendre AWS, Azure et GCP est important. L’octroi de comptes Clouds (de type Infrastructure comme service), à vocation pédagogique nécessite une technologie qui automatise la gouvernance (inscriptions des apprenants, gestion de cycle de vie des comptes, contrôle des accès aux services, gestion des budgets Cloud, suivi et contrôle des apprenants par les enseignants, etc.) que seule RosettaHub permet de fournir a ce jour.

L’accès des étudiants, à tout moment, à des machines virtuelles, dont ils peuvent se servir simplement comme environnements d’apprentissage dans lesquels ils trouvent l’ensemble des outils et des données relatives à un TP ou à un projet ouvre des perspectives importantes d’innovation pédagogique par le numérique. RosettaHub expose des frameworks pour la création, le partage et le suivi de ces environnements d’apprentissage virtualisés permettant un gain de temps considérable aussi bien dans la préparation des environnements, leur réutilisation et leur mise en œuvre par les étudiants en salle de classe et à distance (à la maison).

Donner des comptes Amazon/Azure/Google aux étudiants leur permet, au delà des enseignements prévus dans le cadre de leurs cursus et au delà des projets, de disposer de moyens d’apprendre par eux même des technologies dont l’importance pour l’industrie est réelle et s’accroît de jour en jour. En effet, sur ces plate-formes, de nombreux cours, souvent gratuits, sont également disponibles. L’article [6] donne une vue d’ensemble des nombreuses approches et mécanismes de déploiement d’applications à forte intensité de données dans le nuage. Ces approches gagnent beaucoup d’importance dans les communautés de recherche et industrielles. Les auteurs analysent les différentes décisions de conception de chaque approche et son aptitude à prendre en charge certaines catégories d’applications et d’utilisateurs finaux. Une discussion de certaines questions ouvertes et des défis futurs concernant l’extensibilité, la cohérence et le traitement économique des données à grande échelle sur le nuage est fournie.

(21)

La conteneurisation démontre son efficacité dans le déploiement d’applications dans le Cloud Computing. Les conteneurs peuvent encapsuler des programmes complexes avec leurs dépendances dans des environnements isolés, ce qui rend les applications plus portables. Les articles [7, 8] traitent de la conteneurisation des systèmes à haute performance en calcul (HPC). Singularity8, initialement conçu pour les systèmes HPC, est devenu, de facto, un runtime de conteneurs. Néanmoins, les gestionnaires de charges de travail HPC conventionnels ne prennent pas en charge les micro-services et ne gèrent pas les conteneurs de manière intégrée, contrairement aux orchestrateurs de conteneurs. Les auteurs de [7] introduisent un "Torque-Operator" qui sert de pont entre le gestionnaire de charge de travail HPC (TORQUE) et l’orchestrateur de conteneurs (Kubernetes). Ils proposent alors une architecture hybride qui intègre les clusters HPC et Cloud de manière transparente avec peu d’interférence pour les systèmes HPC où l’orchestration de conteneurs est effectuée à deux niveaux.

Dans [8] les auteurs s’intéressent à conteneuriser l’ordonnanceur de travaux HPC SLURM. Il s’agit de choisir les services à encapsuler, à les faire communiquer et de prévoir une méthodologie pour déployer les services à la demande. L’idée est donc de proposer du "HPC as a Service". Les technologies DevOps sont, quant à elles, discutées dans les références [9, 10, 11, 12]. Dans [9] la discussion s’articule autour de l’observation que la spécialisation, et la diversité des outils qui en résulte, est un aspect fondamental de la chaîne d’outils DevOps moderne. Les auteurs s’interrogent sur la question du comment cela affecte l’architecture de la chaîne de valeur. Dans [10] les auteurs, trois architectes de premier plan, abordent les problématiques du DevOps de front. Les auteurs passent en revue les décisions que les architectes logiciels doivent prendre afin d’atteindre les objectifs de DevOps et précisent comment les autres participants aux projets DevOps sont susceptibles d’avoir un impact sur le travail de l’architecte. Ils fournissent également le contexte organisationnel, technique et opérationnel nécessaire pour déployer le DevOps plus efficacement, et examinent l’impact du DevOps sur chaque phase de développement. Les auteurs abordent également les préoccupations transversales qui lient plusieurs fonctions, en offrant un aperçu pratique de la conformité, des performances, de la fiabilité, de la répétabilité et de la sécurité.

Dans [11] les auteurs constatent qu’en s’appuyant sur les pratiques agiles et allégées, le DevOps signifie alors l’automatisation de bout en bout du développement et de la livraison des logiciels. C’est le point de départ des discussions de l’article qui conclue qu’il existe de nombreux outils qui peuvent aider les développeurs à ce rapprocher du monde des « opérations » et de rompre les silos de fait entre les métiers.

Dans [12] les auteurs présentent un cours sur le DevOps qui est une combinaison de compétences en développement de logiciels et de compétences en exploitation de logiciels. Ce nouveau cours s’adresse aux étudiants de deuxième et troisième année du programme d’informatique qui souhaitent se préparer à une carrière professionnelle dans le domaine du génie logiciel. Le cours pratique en laboratoire fait découvrir aux étudiants Git pour la gestion du code source, Capybara pour les tests automatisés, AWS, Docker et Ansible pour le l’approvisionnement et la configuration automatisés des machines virtuelles, et Jenkins pour l’intégration continue.

(22)

5

Conclusion

Dans ce rapport technique nous avons présenté la solution Bridge-IOTPS qui propose une plate-forme de gestion des services DevOps et des infrastructures Cloud, en anglais nous pouvons parler de DevOps and Cloud Management Platform (DCMP). La présentation introduit le mode graphique puis le mode expert d’exploitation de la plate-forme. Le mode graphique est le mode qui est proposé au « simple utilisateur » afin de gérer les infrastructures Cloud (IaaS), les clusters Kubernetes (CaaS), les services DevOps CI/CD et les équipes IT. Le mode expert est destiné aux organisations avec une expérience en informatique, dont les technologies du DevOps, afin de privilégier le co-développement et faciliter l’accès au modèle opérationnel GitOps. En effet, le mode expert fournit du GitOps as a Service à travers un ensemble d’API Infrastructure as Code permettant de développer et d’automatiser le cycle de vie du développement logiciel. Nous avons aussi, dans ce document, motivé l’approche Bridge-IOTPS et nous l’avons positionné et comparé à des solutions existantes, à la fois provenant du monde académique mais aussi du monde industriel. L’approche permet de faciliter la transformation numérique des organisations, tant publiques que privées, afin de migrer vers les technologies de Cloud, sans pour autant être un expert en Cloud et DevOps (c.f. mode graphique). En effet, la migration s’effectue par l’intermédiaire d’une interface graphique qui masque les complexités de déploiement, configuration et l’approvisionnement des services. Dans son mode plus évolué, dit mode expert, les différentes phases de gestion d’un projet pourront être programmées, par des scripts et des recettes. Ainsi, Bridge-IOTPS est un système complet qui facilite la création et la gestion de bout en bout d’outils DevOps pour les projets de développement logiciels tels que les applications de bureau, les sites Web, les applications mobiles. La solution met également à disposition des outils DevOps pour les applications IoT (Internet des Objets) dans le cadre de projets Edge Computing, pour ne citer que quelques domaines d’application de Bridge-IOTPS.

Références

[1] Mell, Peter M. and Grance, Timothy, "SP 800-145. The NIST Definition of Cloud Computing", 2011, National Institute of Standards & Technology, Gaithersburg, MD, USA.

[2] Sharma, Bhanu and Thulasiram, Ruppa K. and Thulasiraman, Parimala and Garg, Saurabh K. and Buyya, Rajkumar, "Pricing Cloud Compute Commodities : A Novel Financial Economic Model", 2012, IEEE Computer Society, Proceedings of the 2012 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (Ccgrid 2012), https ://doi.org/10.1109/CCGrid.2012.126

[3] Caesar Wu, Rajkumar Buyya, Kotagiri Ramamohanarao, "Cloud Pricing Models : Taxonomy, Survey, and Interdisciplinary Challenges". ACM Comput. Surv. 52(6) : 108 :1-108 :36 (2020). [4] ITU and ALECSO, "Guidelines to improve the use of the Cloud

Computing Technology in Education in Arab Countries", publication disponible en ligne à l’adresse https ://www.itu.int/en/ITU-D/Regional-Presence/ArabStates/Documents/events/2017/NIS/Cloud-guidelines-ITU-Alecso.pdf

[5] Plateforme RosettaHUB pour la prise de ressources en multi-cloud. Site Internet : https ://www.rosettahub.com/welcome

(23)

[6] Sherif Sakr, Anna Liu, Daniel M. Batista, Mohammad Alomari, "A Survey of Large Scale Data Management Approaches in Cloud Environments", IEEE Communications Surveys & Tutorials, 2011, Volume : 13, Issue : 3

[7] Zhou Naweiluo, Georgiou Yiannis, Pospieszny Marcin, Zhong Li, Zhou Huan, Niethammer Christoph, Pejak Branislav, Marko Oskar and Hoppe Dennis, "Container orchestration on HPC systems through Kubernetes", Journal of Cloud Computing, 2021, Volume : 10, Issue : 1 [8] Christophe Cérin, Nicolas Grenèche and Tarek Menouer, "Towards Pervasive Containerization of HPC Job Schedulers", 32nd IEEE International Symposium on Computer Architecture and High Performance Computing, SBAC-PAD 2020, Porto, Portugal, September 9-11, 2020, pages 281–288, https ://doi.org/10.1109/SBAC-PAD49847.2020.00046 [9] M. Kersten, "A Cambrian Explosion of DevOps Tools," in IEEE Software, vol. 35, no. 2, pp.

14-17, March/April 2018, doi : 10.1109/MS.2018.1661330.

[10] Len Weber, Ingo Zhu, Liming Bass, "DevOps : A Software Architect’s Perspective", (SEI Series In Software Engineering) ISBN 13 : 9780134049847 ISBN 10 : 0134049845 Hardcover ; Addison-wesley Professional ; 2015

[11] C. Ebert, G. Gallardo, J. Hernantes and N. Serrano, "DevOps," in IEEE Software, vol. 33, no. 3, pp. 94-100, May-June 2016, doi : 10.1109/MS.2016.68.

[12] R. A. K. Jennings and G. Gannod, "DevOps - Preparing Students for Professional Practice," 2019 IEEE Frontiers in Education Conference (FIE), Covington, KY, USA, 2019, pp. 1-5, doi : 10.1109/FIE43999.2019.9028598.

Biographies

Walid Saad : Maître Assistant en informatique à l’Ecole Nationale d’Ingénieurs de Carthage (Université de Carthage) et membre associé des laboratoires de recherche LaTICE (Université de Tunis) et LIPN (Université Sorbonne Paris Nord, ex Université de Paris 13). Ses activités de recherche portent sur les systèmes distribués à large échelle (Grilles de PCs et Cloud Computing). Il est consultant formateur indépendant en Cloud Computing, transformation DevOps et technologies conteneurs. Il est le créateur du projet Bridge-ITOPS et il pilote ses principales évolutions. Contactez le à l’adressewalid.saad@univ-paris13.fr.

Christophe Cérin : professeur d’informatique à l’Université Sorbonne Paris Nord (ex Université de Paris 13) depuis 2005. Ses recherches portent sur le domaine du calcul haute performance, y compris les grilles de calcul et le Cloud computing. Il développe des intergiciels, des algorithmes, des outils et des méthodes pour la gestion des systèmes distribués. Il est membre de l’IEEE. A ce titre il est actuellement éditeur associé du journal IEEE Transactions on Computers. En 2020 il a reçu le "Research Innovation Award" de la part du IEEE Technical Committee on Cloud Computing. Il agit comme consultant indépendant pour le projet Bridge-IPOps. Par le passé, il a régulièrement participé à des projets industriels, dans le cadre du Fonds unique interministériel (F UI). Sur le territoire de Plaine Commune il travaille actuellement à un projet intitulé « Intelligence ambiante et collective pour le bâtiment de demain ». Contactez le à l’adresse

Figure

Figure 1 – Bridge LABS - Fonctionnement
Figure 4 – Bridge LABS - Kubernetes CaaS
Figure 6 – Bridge LABS - Liste des services DevOps
Figure 7 – Bridge LABS - Créer une pile DevOps ( Drap & Drop ) 2.3.4 Cloud Accounts
+4

Références

Documents relatifs

Il faut disposer également d'une tresse à dessouder dont la largeur est sensiblement égale à la largeur des pistes du circuit imprimer à manipuler.. Remarque : on peut utiliser

Si le service ou un sous-service ne peut pas répondre dans le délai, il doit l’anticiper et répondre par une Demande de prolongation dans la liste déroulante « Réponse » et

- 12 badges « artistes » rangés dans un sac: Andy Warhol, Raymond Hains, Arman, César, Alain Jacquet, Claude Viallat, Sol LeWitt, Yves Klein, Daniel Spoerri (+ Niki de

compétences ne sont pas présentes en interne, et si elles le sont, le web master met plus de temps à réaliser les mises à jour qu'avec un outil de gestion de contenus). Le coût

Il y a plus d'attributs communs entre le chien et la poule (yeux, bouche ; squelette interne ; 4 membres) qu'avec le poisson (yeux, bouche ; squelette interne mais il ne possède pas

ﺩﻋ لﻘﻨ ﺩﻗ ﻲﺴﻝﺩﻨﻷﺍ ﻥﺎﻴﺤ ﺎﺒﺃ ﺩﺠﻨ لﺎﺜﻤﻝﺍ ﺭﻴﺴﻔﺘﻝﺍ ﻲﻓ ﻁﻴﺤﻤﻝﺍ ﺭﺤﺒﻝﺍ ﻪﺒﺎﺘﻜ ﻲﻓ ﻪﻴﻭﻝﺎﺨ ﻥﺒﺍ ﻥﻋ ﺀﺍﺭﺁ ﺓ.

Il faut donc que la durée d'émission d'une trame soit toujours supérieure au temps maximum que celle-ci mettra pour se propager sur le réseau d'une extrémité à l'autre, plus

Ce qui manque à ce paon : c'est bien voir, j'en conviens ; Mais votre chant, vos pieds, sont plus laids que les siens, Et vous n'aurez jamais sa queue. Jean-Pierre Claris de