Au cours de la vie d’un logiciel, beaucoup de temps est consacré à son déploiement sur différentes plates-formes (recette, preprod, prod...). Bien souvent, nous réalisons des sous-projets de création d'environnements pour les logiciels nouvellement développés. 
A la manière de ce qui est fait pour les capacités de calcul et de stockage (avec les API EC2 et S3 d’Amazon par exemple), les autres ressources peuvent aussi être requises à la demande et assemblées à travers des réseaux. C’est la vision de l’Infrastructure agile, où des ressources « standard » sont mises à disposition en self-service via une interface humaine ou par appel de web-services. La figure suivante donne un exemple d’infrastructure réalisée par un tel assemblage :
Ainsi, un système d’information modélisé par des capacités et des réseaux pourrait se réaliser par une « simple » instanciation de ressources « cloud » sans mener « un projet spécifique d’infrastructure ». Vision utopique ou réalité ? Le deuxième choix est déjà le bon !
Il se pose quatre questions essentielles pour réaliser une telle vision :
Nous allons passer en revue ces différents sujets au cours d’une série d’articles sur ce blog. Mais nous pouvons d’ores et déjà en donner un aperçu.
Examinons la dynamique permettant aux utilisateurs d’obtenir des capacités de manière agile. Ces dernières doivent disposer des caractéristiques du « cloud » c’est à dire être :
Prenons par exemple une capacité de transport et routage de messages (Broker MOM). La figure suivante montre un système de déploiement d’application qui invoque l'API de l’Infrastructure agile pour créer une ressource de transport de message :
La ressource de transport de message instanciée (MOM Messaging sur la figure) est composée d’un Broker, d’une console de paramétrage et d’exploitation. Les paramètres d’invocation de la demande précisent les services de messaging souhaités (par exemple les patterns d’intégration que le MOM doit fournir, la qualité de service attendue). Une fois le MOM créé, l’API d’accès à la ressource est active et présente dans ce cas l’accès au Broker. Un SLA définit les qualités opérationnelles de la ressource.
Il y a donc 3 composantes essentielles :
Notre capacité de messaging est donc :
Cette approche est généralisable à toutes les ressources d’infrastructure et de middleware.
Les API sont utilisables depuis par exemple une [usine de développement « 2.0 »](https://blog.octo.com/vers-une-usine-de-developpement-2-0/ "Usine de développement "2.0"") qui consomme de manière intensive l’infrastructure agile :
Grâce à l’Infrastructure agile, les environnements de test et de production sont déployables à la demande. Les Développeurs, devenus Opérateurs applicatifs dans une organisation DevOps, consomment les ressources sans se soucier de la technologie sous-jacente. Ils déploient leurs applications sur des capacités et laissent leurs collègues Opérateurs d’infrastructure assurer l’opération de l’Infrastructure agile selon les SLAs convenus.
Il convient de spécifier fonctionnellement les capacités d’infrastructure et d’indiquer par quels mécanismes techniques l’utilisateur pourra y accéder. Concernant l’aspect fonctionnel, l’essentiel est dans l’organisation : qui participe à la spécification des capacités offertes ? Deux organisations et méthodes projet sont possibles :
Ces deux modes d’engagement de la réflexion débouchent cependant sur un travail de collaboration entre le monde de l’application et celui de l’infrastructure.
Concernant l'aspect technique, quel cadre de spécification et de réalisation utiliser ? Les spécifications EC2, S3, OCCI, font apparaître des spécialisations plus ou moins marquées vers des capacités. Par exemple S3 adresse le stockage et non les MOMs. Il convient de rendre le plus homogène possible l’API afin de constituer un catalogue aisément utilisable et surtout actionnable en terme de combinaison des capacités. Nous examinerons l’utilisation d’OCCI pour une description quasi universelle des capacités d’infrastructure dans un prochain article.
La promesse de l’Infrastructure agile impose de respecter les principes suivants lors de sa conception :
L’Infrastructure agile a deux facettes :
Les composants fournissant les ressources peuvent être utilisés à la fois pour les capacités sous-jacentes et les capacités livrées. Typiquement, la supervision peut fournir des informations sur les machines à l’Opérateur d’infrastructure, mais également des informations concernant les capacités livrées (supervision de VM par exemple) à leurs utilisateurs. Ce double usage est à considérer avec soin, car il entraine la création de contraintes bien spécifiques (sécurité, multi-tenant…).
La figure ci-dessous présente des composants connectés dont les rôles sont les suivants :
Nous aborderons les aspects technologiques et « produits » dans un prochain article.
L’Opérateur de l’Infrastructure agile livre l’API et les capacités aux utilisateurs. Il n’est pas impliqué dans l’usage des capacités livrées, si ce n’est de surveiller leur bon usage et de vérifier que le SLA est bien tenu. On libère ainsi l’Opérateur de toute action applicative pour qu’il se concentre sur son cœur de métier. L’Infrastructure agile doit apporter toutes les métriques à son Opérateur afin qu’il puisse :
La construction de l’Infrastructure agile requiert les compétences d’Architectes d’infrastructure et ne peut plus se satisfaire de déploiement de capacités par silos ou spécialités technologiques. L’Infrastructure agile a une dimension systémique qui requiert une véritable démarche d’architecture assurant cohérence, maîtrise des coûts et capacité d’adaptation aux nouveaux besoins. Examinons ces quelques remarques afin d’en cerner l’aspect :
L’Architecte d’infrastructure qui conçoit et réalise l’Infrastructure agile, apporte son savoir-faire unique qui mixe les technologies d’infrastructure, l’élaboration logicielle et l’intégration de systèmes.
Au cours de cette introduction à l’Infrastructure agile, nous avons proposé d’appliquer les principes du cloud computing à l’ensemble des capacités d’infrastructure. Elles sont alors mises à disposition en self-service, élastiques et payées à la consommation. Une telle infrastructure permet la mise en place de DevOps, en rendant plus clair le contrat de service de l’infrastructure, en libérant les Opérateurs d’infrastructure de l’opération des applications et en poussant l’Opération applicative du coté études. Pour construire l’Infrastructure agile, des compétences d’intégrateur de système et de concepteur/développeur d’application sont nécessaires. L’Architecte d’infrastructure est au cœur de la construction de cette vision. Il nous reste à mettre cette vision en action. Les prochains articles sur ce blog vont nous éclairer sur comment procéder.