Toute tendance technologique s’accompagne inévitablement de termes qui deviennent rapidement si galvaudés qu’ils en perdent pratiquement toute utilité. Au début, le cloud en faisait partie. À certains égards, c’est encore le cas. Il a fallu plusieurs années pour clarifier ce qu’était le DevOps (si tant est que ce soit vraiment fait). Le machine learning et l’IA surfent actuellement pieds nus sur la vague du battage médiatique et ne semblent pas près de tomber.
Juste derrière eux tous vient le « as code ».
Soudain, tout devient « as code ». Le marché n’en a jamais assez, même si la plupart de ses acteurs sont incapables de faire la différence entre C, C++ et C#. L’« as code » est devenu la réponse à la grande question sur la vie, l’univers et le reste. Il n’existe aucun problème que l’« as code » ne puisse résoudre, et tout le monde s’y met.
Lorsque des termes sont employés à tort et à travers, sans limites ni définitions claires, il est important de prendre du recul et de nous assurer que *nos* définitions sont bien précises. Ce serait bien de pouvoir se référer à une définition de type RFC établie par un comité de normalisation, mais il n’en existe pas. Ce qui s’en rapproche le plus, c’est le NIST, et nous avons vu à quel point il a réussi à dissiper la confusion autour du cloud.
Le concept « as code » ne se limite pas à l’infrastructure as code (IAC). Aiman Najjar, de Pythian, a rédigé un excellent aperçu de l’état actuel de l’infrastructure as code. Même si je ne suis pas d’accord avec l’idée que les conteneurs devraient constituer une couche à part entière (du point de vue du réseau et des services applicatifs, il ne s’agit que d’infrastructure), ni avec l’exclusion de Jenkins, son billet de blog permettait globalement de très bien comprendre les relations entre les différentes couches « as code » et d’associer les bons outils aux bons usages. Par ailleurs, la plupart des discussions sur l’infrastructure as code portent sur la livraison continue, c’est-à-dire le pipeline qui compile, teste, intègre et publie une application en production. Ce processus n’est pas le même que celui du déploiement continu, qui consiste à prendre l’application publiée et à la déployer dans un environnement de production avec les services réseau et applicatifs dont elle a besoin.
REMARQUE Dans un monde applicatif idéal, les pipelines de livraison et de déploiement convergent. Mais la plupart d’entre nous vivent (encore) dans la réalité des applications, où les environnements de production et de développement sont distincts et soumis à des exigences et contraintes différentes. Il est donc nécessaire de tenir compte de cette séparation lorsque nous automatisons le pipeline.
Trois couches distinctes se dessinent pour prendre en charge les particularités inhérentes à l’informatique et au pipeline de déploiement. La première d’entre elles concerne la complexité intrinsèque de l’environnement. La ligne droite reliant le client à l’application que nous traçons dans les schémas réseau ne trompe personne. Il se passe tout simplement bien plus de choses en coulisses que nous n’avons le temps (et la patience) de représenter.
La diversité du pipeline lui-même — qui comprend du matériel spécialement conçu ainsi que des logiciels virtualisés et conteneurisés déployés sur du matériel standard (COTS) — justifie également de scinder l’approche « as code » en plusieurs couches distinctes. S’il est vrai que le matériel plus récent peut être géré selon une approche « as code », il peut être quasiment impossible d’intégrer le matériel ancien (partagé) au processus. La séparation des couches, afin de mieux refléter le processus de déploiement lui-même, permet donc d’inclure dans le pipeline aussi bien des solutions matérielles anciennes et modernes que des services logiciels.
L’objectif est de mettre en place une pile informatique continue capable de prendre en charge, pour chaque application, des calendriers de déploiement et des architectures propres dans un environnement multicloud. Et puisque le déploiement ne constitue que le début du cycle de vie actif d’une application, une quatrième couche doit être consacrée aux opérations post-déploiement. Elle vient s’ajouter aux trois couches principales couvrant le provisionnement et l’intégration de l’infrastructure, la configuration et la gestion des services, ainsi que le pipeline de déploiement.
La liste des outils ne doit pas être considérée comme exhaustive. Il existe de nombreux autres outils et ensembles d’outils. Par exemple, plusieurs enquêtes et études nous ont appris que la majorité des équipes NetOps préfèrent utiliser des scripts Python sur mesure pour automatiser les services réseau et applicatifs. Nous savons également que les systèmes et piles d’automatisation réseau tels que Cisco ACI, VMware NSX, OpenStack et Red Hat OpenShift sont des solutions couramment utilisées pour mettre en œuvre de nombreuses fonctions de la pile d’opérations continues. Le visuel ne permet tout simplement pas d’inclure tous les outils ; une sélection a donc été établie en fonction de leur popularité auprès des équipes DevOps. En effet, la standardisation de l’ensemble du pipeline de livraison et de déploiement sera une composante essentielle de la réussite, et il est difficile de contester l’intérêt de tirer parti des compétences et de l’expertise déjà présentes dans votre organisation en utilisant les outils les plus couramment employés pour mettre en œuvre des pipelines de livraison « as code ». À noter que je n’ai répertorié aucun outil pour les « opérations as code », car nombre d’entre eux sont conçus sur mesure (scripts personnalisés) ou propres à la technologie d’un fournisseur, du moins pour l’instant.
REMARQUE L’exploitation sous forme de code est l’équivalent informatique de la gestion des processus métier (BPM). La BPM permet d’automatiser les processus métier. Certaines approches de BPM se concentrent uniquement sur des workflows très spécifiques, tandis que d’autres peuvent couvrir l’intégralité d’une interaction client, de l’achat à la livraison en passant par le paiement. Aujourd’hui, l’exploitation sous forme de code est une pratique émergente dans le domaine informatique, mais elle devra évoluer vers une gestion des processus opérationnels pour que les entreprises puissent tirer parti de leur optimisation, comme elles ont appris à exploiter les avantages de la BPM.
Pile d’exploitation continue
Infrastructure en tant que code (IaC)
Que ce soit dans le cloud ou dans le centre de données, il reste toujours un réseau à configurer. Même les services de niveau supérieur (ceux qui fonctionnent au niveau des couches 4 à 7, également appelés services applicatifs) nécessitent une certaine connaissance de la topologie du réseau pour fonctionner. Certains d’entre eux peuvent devoir être activés (c’est-à-dire faire l’objet d’une licence) si vous déployez un tout nouveau pipeline. L’Infrastructure as Code est indispensable pour permettre une approche du déploiement en libre-service, car sans l’infrastructure (logiciels et services) en place, il n’y a rien à configurer ni aucun environnement sur lequel déployer une application.
Responsabilités : infrastructure intégration, gestion des licences et provisionnement
Configuration en tant que code (CaC)
Il s’agit d’une problématique distincte de la configuration, laquelle répond précisément à la nécessité de définir les règles et le comportement propres au service concerné. La configuration peut être renouvelée à chaque mise à jour majeure de l’application, mais aussi à chaque mise à jour mineure. Pour les services liés à la sécurité, elle peut être effectuée en urgence afin d’appliquer un correctif, une mise à jour ou une mise à niveau à un service donné. La configuration en tant que code est essentielle pour prendre en charge les calendriers et pipelines de déploiement propres à chaque application, ainsi que pour imposer l’isolation des chemins d’accès aux données des applications, indispensable à la stabilité globale du pipeline de production.
Responsabilités : configuration du service et mise à niveau et application des correctifs
Pipeline en tant que code (PaC)
Il y a ensuite le processus global qui définit l’ensemble de l’application et de ses services, du début à la fin. Il s’agit du pipeline complet, codifié sous la forme d’un processus exécutable qui pilote automatiquement le déploiement. Le pipeline en tant que code (PaC) constitue le lien entre l’IaC et la CaC, et les réunit pour former ce que l’on appelle un pipeline de déploiement. C’est au niveau du pipeline que les gains de rapidité et d’efficacité seront les plus importants, car il permet d’éliminer les temps d’attente entre les différentes étapes du processus.
Responsabilités : automatisation du processus de déploiement
Opérations en tant que code (OaC)
Cette couche correspond aux opérations courantes. C’est là qu’interviennent la surveillance et les alertes, la mise à l’échelle automatique et la découverte. Dans cette couche, il s’agit de codifier les processus opérationnels au sein d’un système capable de les exécuter de manière autonome. La mise à l’échelle automatique est l’un des processus opérationnels les plus souvent codifiés et fait intervenir plusieurs systèmes. Toutefois, la collecte de données de télémétrie à des fins d’analyse est un autre processus opérationnel qui nécessite une attention particulière, tout comme les actions susceptibles d’être entreprises sur la base de ces données afin de permettre des ajustements (automatiques) visant à optimiser le chemin des données ou les performances des applications. Ces processus opérationnels disposent de leur propre configuration et interviennent après la fin du processus de déploiement.
Responsabilités : automatisation des workflows opérationnels
Envisager le déploiement continu sous l’angle de la pile d’opérations continues permet d’adopter une approche stratégique de l’automatisation du pipeline de production. La séparation des couches et des responsabilités facilite la prise en charge de la tâche particulièrement ardue que représente l’automatisation des activités informatiques, tout en favorisant l’approche en libre-service souhaitée par de nombreuses organisations et de plus en plus exigée par les métiers. Elle ouvre également la voie aux opérations continues grâce aux opérations en tant que code, une évolution nécessaire de l’utilisation de l’automatisation au sein de l’informatique.
Cela dit, ce n’est peut-être pas la « seule et unique bonne façon » d’envisager les efforts d’automatisation associés au pipeline de déploiement. Mais c’est une façon de faire, qui permet aux acteurs du marché d’indiquer clairement ce qu’ils font ou ne font pas.
Cela signifie que vous pouvez savoir avec certitude ce que j’entends lorsque je parle d’« infrastructure en tant que code » ou de « configuration en tant que code », notamment en ce qui concerne les produits F5.
À propos de l’auteur
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 VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.