Les services applicatifs et le pipeline CD

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Comme toute technologie qui finit par dominer les discussions autour des centres de données, le DevOps souffre actuellement d’une lassitude face aux tentatives de définition. À ce stade, je pense même qu’il s’agit d’épuisement, mais la frontière entre les deux est difficile à établir. Autant dire que le DevOps est aussi loin de faire l’objet d’une définition universellement acceptée que le cloud et le SDN.

Mais le DevOps a ceci de particulier que les concepts qui le composent sont eux aussi souvent confondus et amalgamés. Par exemple, CD peut désigner la « livraison continue » ou le « déploiement continu ». Or, ces deux notions ne sont pas identiques et ne doivent être ni confondues ni amalgamées. Puppet Labs a parfaitement illustré cette différence dans un article de blog:

Vous remarquerez que la différence fondamentale réside dans le fait que le déploiement en production est « manuel » (livraison continue) ou « automatisé » (déploiement continu).

Le fait est que cette petite case orange intitulée « déployer en production » recouvre une quantité considérable de tâches qui doivent être automatisées. Il ne s’agit pas seulement de déployer l’application et ses dépendances (bases de données, autres services, infrastructure, etc.). Il faut également déployer tous les services réseau et applicatifs nécessaires pour fournir cette application à l’utilisateur final. C’est là que les services applicatifs entrent en jeu et que la fourniture d’applications (au sens de la production, et non du développement) s’intègre au pipeline de déploiement continu.

Pour automatiser l’étape de « déploiement en production » au sein du pipeline de déploiement continu, de nombreux éléments doivent être provisionnés, configurés et testés. Cela englobe aussi bien les services réseau de base que les services de sécurité (comme les pare-feu), de disponibilité (répartition de charge) et de performance (accélération, mise en cache, etc.). En moyenne, les entreprises utilisent 11 services différents de mise à disposition des applications pour répondre à leurs besoins en applications rapides, sécurisées et disponibles. Chacun de ces services doit être déployé (provisionné et configuré), et certains dépendent du déploiement d’autres services.

Chacun de ces services (c’est un peu comme l’énigme de St Ives, pour ceux qui suivent) possède un nombre variable de paramètres à configurer : options à activer ou désactiver, algorithmes à sélectionner, routes à établir, etc.

En d’autres termes, passer du mode « manuel » au mode « automatique » est loin d’être aussi simple qu’il n’y paraît.

Qu’est-ce qui ralentit le réseau ?

Un obstacle majeur à l’automatisation de ces processus réside dans les différences entre les composants partagés et ceux propres à chaque application. L’infrastructure en tant que code est possible dans le domaine de l’infrastructure applicative précisément parce que nous pouvons dédier une infrastructure (comme un serveur web ou un répartiteur de charge) à une application. Son fichier de configuration s’apparente donc à un microservice : il est localisé et axé sur la fourniture de services à une seule application.

Lorsque l’on passe au monde des réseaux et des services applicatifs, ce n’est pas toujours le cas. Un routeur ou un commutateur, par exemple, est conçu pour fournir des services de connectivité et de transfert à plusieurs applications. Cela signifie que les fichiers de configuration couvrent nécessairement plusieurs applications. Bien que la gestion des versions puisse être utile dans ce cas, il n’en reste pas moins que les configurations sont étroitement liées à un appareil, et non à une application. Il en va de même pour les services applicatifs et la sécurité.

Ainsi, même s’il est très positif que nous évoluions tous vers un monde où l’API remplace la CLI, nous devons également répondre à la nécessité de prendre en charge un modèle par application (ou centré sur les applications, si vous préférez), dans lequel les configurations peuvent être gérées application par application.

Cela implique d’évoluer vers une architecture réseau de type microservices, dans laquelle les services sont déployés et configurés application par application. Cela peut prendre la forme soit d’« appareils » dédiés (virtuels ou matériels, le format n’ayant aucune importance dans le cadre de cette discussion), soit de configurations propres à chaque application, telles que des modèles.

Sommes-nous déjà arrivés à ce stade ?

Nous nous rapprochons du but grâce à des modèles déclaratifs de provisionnement et de gestion qui utilisent des API pour déployer des modèles (c’est ce qu’on appelle l’infrastructure en tant que code) pour chaque application, mais nous n’y sommes pas encore. Il reste encore beaucoup à faire pour déterminer comment orchestrer l’automatisation nécessaire à la réussite du déploiement continu.

Les silos liés au réseau, à l’infrastructure, aux services applicatifs et à la sécurité doivent être pris en compte si nous voulons passer du « manuel » à l’« automatique » pour cette étape de « mise en production », essentielle pour achever la transition de la livraison continue au déploiement continu. Cela implique davantage de travail au niveau de l’automatisation, ainsi qu’une orchestration globale permettant d’automatiser entièrement les processus qui aboutissent au déploiement continu en production.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie