L'Infrastructure agile
Les principes de l’Infrastructure agile
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 :
- Comment définir et gouverner les ressources utiles aux usages de l’entreprise (périmètre fonctionnel, modèle de financement et de facturation aux utilisateurs, SLA) ?
- Comment donner aux utilisateurs l’accès à ces ressources ?
- Comment implémenter les ressources à fournir (architecture, technologies) ?
- Comment opérer techniquement les ressources ?
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.
Un exemple de fonctionnement
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 :
- disponibles dès que demandées via une interface humaine ou programmatique (approche « à la demande ») ;
- payées à la consommation ;
- en ligne avec un SLA donné ;
- de capacité infinie vue de l’utilisateur.
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 :
- L’API de demande de mise à disposition, qui une fois invoquée déclenche la création de la ressource et la mise à disposition des informations d’usage à l’utilisateur (réponse au web-service de demande ou vue dans le portail) ;
- L’API d’usage des ressources qui permet l’accès aux capacités créées ;
- Le Portail qui offre une vue d’interface humaine sur les ressources créées et utilisées.
Notre capacité de messaging est donc :
- Disponible à la demande via une API (ou une IHM style « portail ») ;
- De capacité infinie car on peut créer autant de brokers que l’on souhaite ;
- Facturable au broker instancié et aux trafic de messages effectif ;
- Ajustée en fonction d’un SLA définissant la disponibilité du service, sa fiabilité et ses performances maximales (niveau de disponibilité, latence de transmission...).
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.
Comment découvrir et préciser les capacités de l’Infrastructure agile ?
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 :
- Le marketing interne proactif, c’est à dire que les responsables de l’infrastructure sont à l’initiative et démarchent les utilisateurs de façon anticipée pour découvrir quelles capacités sont ou seront requises ;
- La réalisation réactive, où les responsables de l’infrastructure attendent les demandes (venant des équipes de développement la plupart du temps) pour faire évoluer leurs actifs dans un but de factorisation et de rationalisation progressive.
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.
Comment réaliser et opérer l’Infrastructure agile ?
La promesse de l’Infrastructure agile impose de respecter les principes suivants lors de sa conception :
- Automatisation totale, pour obtenir une qualité « industrielle » ;
- Standardisation totale des composants (matériel, logiciel), pour réduire les coûts ;
- Opération dédiée, pour libérer l’Opérateur d’infrastructure qui ne connaît plus les applications mais se focalise sur le SLA des capacités livrées.
Architecture
L’Infrastructure agile a deux facettes :
- Les ressources matérielles et logicielles (Machines, OS, stockage… qui permettent de livrer les ressources requises via l’API de mise à disposition). On appelle ces ressources des « Capacités sous-jacentes », non visibles en tant que telles par les utilisateurs de l’API ;
- Les ressources effectivement livrées et fonctionnant dans un contexte utilisateur (VM, VLAN, Consoles de supervision, stockages…), ce sont les « Capacités livrées ».
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…).
Composants essentiels
La figure ci-dessous présente des composants connectés dont les rôles sont les suivants :
- L’inventaire et la CMDB recensent le parc des ressources composant l’Infrastructure agile (du point de vue des capacités) ;
- Le Configuration manager a pour objectif de maintenir la configuration à jour de tous les composants utiles à la livraison des capacités. Il est aussi en charge de la configuration élémentaire des capacités livrées ;
- Le Cloud controller, en association avec le Configuration manager provisionne les capacités demandées via l’API ;
- La supervision surveille les capacités sous-jacentes et livrées ;
- Le réseau permet de composer dynamiquement des sous réseaux respectant des politiques de communication et de sécurité ;
- Un système de stockage est utilisé pour fournir de l’espace sous-jacent ou livré ;
- Un pool de machines homogène et supportant la virtualisation fournit la puissance de calcul.
Nous aborderons les aspects technologiques et « produits » dans un prochain article.
Opération de l’Infrastructure agile
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 :
- Superviser l’ensemble des ressources sous-jacentes ;
- Etablir le capacity planning moyen terme et le travailler avec les équipes de développement et le Métier ;
- Anticiper les maintenances ;
- Préparer la facturation des capacités livrées consommées ;
- Participer au plan d’évolution de l’Infrastructure agile avec les Architectes d’infrastructure ;
- Conduire les tests de l’Infrastructure agile avec les Architectes d’infrastructure.
L’architecte d’infrastructure
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’Infrastructure agile se comporte comme une application informatique traditionnelle vue des utilisateurs. En effet, ces derniers voient une API programmatique et un Portail ;
- De ce fait, les principes d’élaboration des applications/systèmes d’information sont applicables. Par exemple, il convient de définir les cas d’usages de l’Infrastructure agile (Utilisateur / Opérateur), les cas de test, le comportement interne (règles de gestion…) ;
- L’Infrastructure agile est réalisée par l’intégration de produits. Il faut les maîtriser (cartographies fonctionnelles, capacités opérationnelles), puis étudier l’architecture applicative et technique complète, réaliser les dimensionnements des composants, étudier les flux inter-composants, les modes dégradés…
- L’automatisation poussée impose souvent de complémenter les produits par du code spécifique (optimiseurs, ordonnanceurs, règles de gestion) ;
- Il convient de livrer l’Infrastructure agile en mode itératif afin de suivre les besoins de capacités exprimés notamment par les Équipes de développement et Métiers. Une usine de développement et de tests pour l’Infrastructure agile est donc nécessaire.
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.
Conclusion
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.