Services application et pipeline CD
Comme c’est le cas pour toutes les technologies qui dominent les conversations sur les centres de données, DevOps souffre actuellement d’une fatigue de définition. En fait, à ce stade, je pense que c’est l’épuisement, mais la frontière entre les deux est difficile à déterminer. Il suffit de dire que DevOps est aussi loin d’avoir une définition universellement acceptée que le cloud et le SDN.
Mais DevOps est unique dans le sens où ses concepts composites sont souvent confondus et confondus. Par exemple, CD peut être interprété comme signifiant « livraison continue » ou « déploiement continu ». Ces deux termes ne sont pas identiques et ne doivent pas non plus être confondus ou confondus. Puppet Labs a fait un excellent travail en illustrant la différence dans un article de blog :
Vous remarquerez que la différence déterminante réside dans le fait que le déploiement en production soit « manuel » (livraison continue) ou « automatisé » (déploiement continu).
Le problème est qu’il y a une quantité importante de travail dans cette petite boîte orange intitulée « déployer en production » qui doit être automatisée. Il ne s’agit pas simplement de déployer l’application et ses dépendances (bases de données, autres services, infrastructure, etc…). Il s’agit également de déployer tous les services réseau et application nécessaires pour fournir cette application au consommateur final. C'est là qu'interviennent les services application et que la livraison application (au sens de la production, et non au sens du développement) entre dans le pipeline de déploiement continu.
Afin d’automatiser l’étape « déployer en production » dans le pipeline de déploiement continu, de nombreux éléments mobiles doivent être provisionnés, configurés et testés. Cela signifie tout, depuis la mise en réseau de base jusqu'à la sécurité (comme les pare-feu), en passant par la disponibilité (équilibrage de charge) et les services de performance (accélération, mise en cache, etc.). En moyenne, les organisations utilisent 11 services de distribution application différents pour répondre à leurs besoins en applications rapides, sécurisées et disponibles. Chacun doit être déployé (provisionné et configuré) et certains dépendent du déploiement des autres.
Chacun de ces services (c'est comme l'énigme de St. Ives, pour ceux d'entre vous qui jouent) a un nombre variable de caractéristiques qui doivent être configurées, des options définies sur vrai ou faux, des algorithmes sélectionnés, des itinéraires établis, etc…
En d’autres termes, passer du mode « manuel » au mode « automatique » n’est pas aussi simple qu’il y paraît.
Qu’est-ce qui freine le réseau ?
Un obstacle important à l’automatisation de ces processus réside dans les différences entre les composants partagés et ceux par application. L'infrastructure en tant que code est possible dans le domaine de l'infrastructure des applications précisément parce que nous pouvons dédier une infrastructure (comme un serveur Web ou un équilibreur de charge) à une application. Cela signifie que son fichier de configuration est en quelque sorte un microservice : il est localisé et axé sur la fourniture de services pour une seule application.
Lorsque nous passons au monde des réseaux et des services d’applications, ce n’est pas toujours le cas. Un routeur ou un commutateur, par exemple, est spécialement conçu pour fournir des services de connectivité et de transfert pour plusieurs applications. Cela signifie que les fichiers de configuration englobent nécessairement plusieurs applications. Même si le contrôle de version peut s'avérer utile dans ce cas, il n'en demeure pas moins que les configurations sont étroitement liées à un appareil et non à une application. Il en va de même pour les services d'application et la sécurité.
Même s’il est vrai que nous évoluons tous vers un monde où l’API est la CLI, nous devons également répondre à la nécessité de prendre en charge un paradigme par application (ou centré sur l’application, si vous préférez) où les configurations peuvent être gérées application par application .
Cela signifie é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 de « périphériques » dédiés (virtuels ou matériels, le facteur de forme n'est pas pertinent dans le cadre de cette discussion) ou de configurations spécifiques à l'application comme des modèles .
On y est déjà ?
Nous nous rapprochons, avec des modèles déclaratifs pour l'approvisionnement et la gestion qui utilisent des API pour déployer des modèles (c'est-à-dire une infrastructure en tant que code) pour chaque application, mais nous n'y sommes pas encore. Il reste encore beaucoup de travail à faire pour déterminer comment orchestrer l’automatisation nécessaire pour permettre un déploiement continu pleinement réussi.
Le réseau, l'infrastructure, les services d'application et les silos de sécurité doivent être inclus si nous voulons passer du « manuel » au « automatique » pour cette étape de « déploiement en production » qui est essentielle pour achever le passage de la livraison continue au déploiement continu. Et cela signifie davantage de travail au niveau de la couche d’automatisation ainsi que de l’orchestration globale nécessaire pour automatiser entièrement les processus qui conduisent finalement au déploiement continu en production.