En tant que code : La pile informatique continue
Il existe toujours, dans toute tendance technologique, des termes qui deviennent rapidement si en vogue qu’ils peuvent devenir pratiquement inutiles. Au commencement, Cloud était un. D'une certaine manière, c'est toujours le cas. Il a fallu plusieurs années pour mettre en place DevOps (si tant est qu'il y parvienne). L’apprentissage automatique et l’IA surfent actuellement pieds nus sur la vague du buzz et ne montrent aucun signe de disparition prochaine.
Juste derrière eux se trouve « as code ».
Soudain, tout est « as code ». Le marché ne peut pas se passer du « as code », même si la plupart des gens ne savent pas faire la différence entre C, C++ et C#. « As code » est devenu la réponse à la vie, à l’univers et à tout. Il n’y a aucun problème que le « code as-code » ne puisse résoudre, et tout le monde le fait.
Il est important, lorsque des termes sont utilisés sans limites ni définitions claires, que nous fassions une pause et que nous nous assurions que nous sommes clairs sur *nos* définitions. Il serait bien qu'il y ait un comité de normalisation avec une définition de style RFC à laquelle se référer, mais ce n'est pas le cas. Le plus proche dont nous disposons est le NIST, et nous avons vu à quel point ils ont réussi à résoudre l'énigme du cloud.
Le « as-code » ne se résume pas seulement à une infrastructure en tant que code (IAC). Aiman Najjar @ Pythian a rédigé un excellent aperçu du paysage actuel de l'infrastructure en tant que code . Bien que je ne sois pas d'accord avec le fait que les conteneurs devraient être leur propre couche (ce n'est qu'une infrastructure du point de vue du réseau et des services d'application) et que Jenkins n'en fait pas partie, en général, son blog était un excellent moyen de comprendre la relation entre les couches « en tant que code » et de cartographier les bons outils pour le bon travail. De plus, la plupart des discussions sur l’infrastructure en tant que code se concentrent sur la livraison continue, c’est-à-dire le pipeline qui crée, teste, intègre et publie une application en production. Il ne s’agit pas du même processus que le déploiement continu, qui se concentre sur la prise de l’application publiée et son déploiement dans un environnement de production avec les services réseau et applicatifs requis.
REMARQUE Dans App Utopia, les pipelines de livraison et de déploiement sont convergés. Mais la plupart d’entre nous vivent (encore) dans une réalité d’application, où la production et le développement sont des environnements distincts avec des ensembles d’exigences et de contraintes différents. D’où la nécessité de reconnaître cette séparation lorsque nous appliquons l’automatisation au pipeline.
Il existe trois couches distinctes qui s'élèvent pour couvrir les excentricités inhérentes à l'informatique et au pipeline de déploiement. Le plus important d’entre eux est la complexité inhérente à l’environnement. Cette ligne droite reliant le client à l’application que nous traçons dans les diagrammes de réseau ne trompe personne. Il se passe tout simplement beaucoup plus de choses sous le capot que ce que nous avons le temps (et la patience) de schématiser.
La diversité du pipeline lui-même, comprenant du matériel spécialement conçu ainsi que des logiciels virtuels et basés sur des conteneurs déployés sur des COTS, fournit également l'impulsion nécessaire pour découper et découper « en tant que code » en couches distinctes. S'il est vrai que le matériel plus moderne peut être géré via une approche as-code, le matériel hérité (partagé) peut être presque impossible à intégrer dans le processus. Séparer les couches pour refléter plus fidèlement le processus de déploiement lui-même peut alors fournir un moyen d'inclure à la fois des solutions matérielles héritées et modernes ainsi que des services logiciels dans le pipeline.
L’objectif est de créer une pile informatique continue capable de prendre en charge les calendriers de déploiement et les architectures par application dans un environnement multi-cloud. Et comme le déploiement n’est que le début du cycle de vie actif d’une application, il doit y avoir une quatrième couche qui se concentre sur les opérations post-déploiement. Cela s'ajoute aux trois couches principales couvrant le provisionnement et l'intégration de l'infrastructure, la configuration et la gestion des services et 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, nous savons, grâce à de nombreuses enquêtes et recherches, que la majeure partie des NetOps préfère les scripts Python sur mesure pour la tâche d’automatisation des services réseau et applicatifs. Nous savons également que les systèmes et piles d’automatisation de réseau tels que Cisco ACI, VMware NSX, OpenStack et Red Hat OpenShift sont des moyens populaires de mettre en œuvre de nombreuses fonctions dans la pile d’opérations continues. Il n'y a tout simplement pas assez de place dans le visuel pour inclure tous les outils, et donc un échantillon a été inclus en fonction de la popularité des outils avec DevOps. Cela est dû au fait que la standardisation de l'ensemble du pipeline de livraison et de déploiement sera un élément essentiel du succès et qu'il est difficile de s'opposer à l'exploitation des compétences et de l'expertise existantes dans votre organisation avec les outils les plus couramment utilisés pour mettre en œuvre des pipelines de livraison « en tant que code ». Il convient de noter que je n'ai répertorié aucun outil pour les « opérations en tant que code » car beaucoup d'entre eux sont sur mesure (scripts personnalisés) ou spécifiques à une technologie de fournisseur - du moins pour l'instant.
REMARQUE Les opérations en tant que code sont l’équivalent informatique de la gestion des processus métier (BPM). Avec le BPM, les processus métier sont automatisés. Certains BPM se concentrent uniquement sur des flux de travail très spécifiques, d'autres peuvent couvrir la longueur et l'étendue d'une interaction client, de l'achat au paiement jusqu'à la livraison. Les opérations en tant que code sont une pratique naissante dans l'informatique aujourd'hui, mais elles devront évoluer vers la gestion des processus opérationnels si les entreprises veulent pouvoir capitaliser sur l'optimisation des processus opérationnels de la même manière qu'elles ont appris à tirer parti du BPM.
Pile d'opérations continues
Infrastructure en tant que code (IaC)
Que ce soit dans le cloud ou dans le centre de données, il existe toujours un réseau qui doit être configuré. Même les services d'ordre supérieur (ceux fonctionnant aux couches 4 à 7, également appelés services d'application) nécessitent une certaine connaissance de la topologie du réseau pour fonctionner. Certains d'entre eux devront peut-être être activés (c'est-à-dire sous licence) si vous déployez un tout nouveau pipeline. L'infrastructure en tant que code est nécessaire pour permettre une approche de déploiement en libre-service, car sans l'infrastructure (logiciel et services) en place, il n'y a rien pour configurer ou déployer une application.
Responsabilités : intégration de l'infrastructure , licences, approvisionnement
Configuration en tant que code (CaC)
Il s’agit d’un problème distinct de la configuration, qui évoque spécifiquement la nécessité de configurer la politique et le comportement spécifiques au service en question. La configuration peut se reproduire à chaque mise à jour majeure de l'application. Cela peut également se reproduire à chaque mise à jour mineure. Pour les services liés à la sécurité, il peut être nécessaire d'appliquer un correctif, de mettre à jour ou de mettre à niveau un service donné en cas d'urgence. La configuration en tant que code est essentielle pour prendre en charge les planifications et les pipelines de déploiement par application, et pour renforcer l'isolement des chemins de données d'application, importants pour garantir la stabilité du pipeline de production dans son ensemble.
Responsabilités : configuration, mise à niveau et correctifs du service
Pipeline en tant que code (PaC)
Ensuite, il y a le processus global qui définit l’ensemble de l’application et ses services du début à la fin. Il s’agit de l’ensemble du pipeline, et il est codifié dans un processus exécutable qui pilote automatiquement le déploiement. Pipeline as code est le lien entre IaC et CaC qui les relie pour décrire ce que nous appelons un pipeline de déploiement. C’est au niveau du pipeline que l’on trouvera les plus grands gains de rapidité et d’efficacité, car il permet d’éliminer les temps d’attente entre les étapes nécessaires au processus.
Responsabilités : automatisation du processus de déploiement
Opérations en tant que code (OaC)
Cette couche est la couche opérationnelle en cours. C'est là que se produisent la surveillance et les alertes, la mise à l'échelle automatique et la découverte. Dans cette couche, nous nous intéressons à la codification des processus opérationnels dans 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 implique plusieurs systèmes. Mais la collecte 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 possibles entreprises sur la base de cette télémétrie qui permettent des ajustements (automatiques) pour optimiser le chemin de données ou les performances de l’application. Ces processus opérationnels ont leur propre configuration et entrent en jeu une fois le processus de déploiement terminé.
Responsabilités : automatisation des flux de travail opérationnels
Considérer le déploiement continu à travers le prisme de la pile d’opérations continues peut fournir une approche stratégique pour automatiser le pipeline de production. En séparant les couches et les responsabilités, il est plus facile d’aborder la tâche très ardue d’automatiser les tâches informatiques d’une manière qui permet l’approche de libre-service souhaitée par de nombreuses organisations et de plus en plus demandée par l’entreprise. Il permet également un chemin vers des opérations continues via des opérations en tant que code, ce qui constitue une évolution nécessaire dans l'utilisation de l'automatisation au sein de l'informatique.
Cependant, cela n’est peut-être pas la « seule véritable façon » de considérer les efforts d’automatisation associés au pipeline de déploiement. Mais c’est une façon de faire, et cela donne au marché la possibilité de dire clairement ce qu’il fait ou ne fait pas.
Cela signifie que vous pouvez être certain de ce que je veux dire lorsque je parle d'infrastructure en tant que code ou de configuration en tant que code , en particulier en ce qui concerne les produits F5.