L’intégration a toujours été un gros mot, en ce sens qu’elle évoque les grincements de dents et les lamentations de ceux qui s’éternisent sur des projets consacrés à sa mise en œuvre. De fait, 59 % des décideurs informatiques ont qualifié « l’intégration de “talon d’Achille” de leur organisation ». (Rapport 2018 sur l’intégration des entreprises connectées)
À première vue, l’intégration repose sur un principe simple : comment partager des données entre différentes applications ? Car aucune application — même monolithique — ne fonctionne en vase clos. Je n’ai encore jamais rencontré d’application qui ne partageait pas au moins une donnée avec une autre application.
Nous (c’est-à-dire le secteur dans son ensemble) avons traversé plusieurs ères en matière d’intégration. Des modèles en étoile aux bus de services d’entreprise, en passant par les files de messages, l’intégration reste une composante essentielle de toute stratégie d’applications d’entreprise.
Nous ne parlons plus d’intégration des applications d’entreprise (EAI), principalement parce que je pense que cela effraie les jeunes et déclenche des crises d’apoplexie chez les anciens comme nous, mais nous utilisons toujours le mot « intégration ». Et nous l’employons de plus en plus en dehors du monde du développement d’applications. Après tout, CI signifie intégration continue. Nous considérons également l’intégration comme un élément important du déploiement (en production). Et nous constatons autant de frustration que chez nos homologues du développement d’applications, comme en témoignent ceux qui déplorent le manque d’outils intégrés lorsqu’ils doivent automatiser le réseau.
Les opérations ont besoin d’intégration. Sans elle, nous ne pouvons pas automatiser les processus (ce qui constitue précisément l’orchestration), car ceux-ci couvrent nécessairement plusieurs systèmes, services et appareils, chacun étant susceptible de disposer de son propre domaine opérationnel et de ses propres outils. Sans intégration, impossible de créer un pipeline et, sans pipeline, les équipes opérationnelles seront submergées par le besoin croissant de déploiements fréquents à la demande.
C’est là que l’infrastructure en tant que code et les dépôts peuvent apporter une solution. Les dépôts ne sont pas seulement des espaces où stocker pratiquement tout type d’artefact, qu’il s’agisse de fichiers de configuration, de programmes Python, de scripts ou de modèles. Ils peuvent jouer un rôle actif dans votre pipeline de déploiement (intégré).
Les dépôts sont bien plus que de simples coffres de stockage
Les dépôts ne servent pas uniquement à stocker des artefacts. Certes, c’est leur fonction première, mais ils sont devenus bien plus que de simples espaces de stockage. Aujourd’hui, des dépôts comme GitLab et GitHub peuvent constituer un élément clé du pipeline automatisé. Grâce aux déclencheurs et aux événements, les dépôts servent non seulement à stocker des artefacts, mais aussi d’outils au sein d’une chaîne d’outils plus vaste. Un commit lance une tâche qui, une fois terminée, appelle un webhook déclenchant l’étape suivante du pipeline.
Qu’est-ce qu’un webhook ?
Parfois appelé « API inversée », un webhook permet à une application, telle qu’un dépôt, d’envoyer des données en temps réel à une autre application via une URL/API. Par exemple, lorsqu’une nouvelle configuration de votre répartiteur de charge est validée, le dépôt déclenche un webhook qui envoie à son tour la configuration, ou son URI, à une application (ou directement au répartiteur de charge), laquelle charge ensuite la nouvelle configuration.
En résumé, nous utilisons les dépôts à peu près comme nous utilisions autrefois un bus de services d’entreprise pour partager des données et déclencher des actions dans différentes applications et différents services afin de mener à bien un « processus ». Dans le monde de l’entreprise, ce processus peut consister à traiter une commande client et faire intervenir le système d’information client (CIS), un système de traitement des commandes, la facturation et certains éléments de la chaîne d’approvisionnement.
Dans le domaine des opérations, ce processus englobe les services d’infrastructure, de réseau et de sécurité nécessaires au déploiement d’une application ou d’une politique.
Plus intéressant encore pour ceux qui ont cité les « compétences » comme leur principal défi : les dépôts peuvent être gérés presque exclusivement depuis la ligne de commande. Oui, en utilisant les compétences que possèdent déjà la plupart des équipes NetOps. Un peu de bash et de PERL*, une API via curl, et le tour est joué !
Cela ne répond toutefois pas au besoin plus profond d’intégration au niveau des équipements, qui se traduit par la frustration liée au manque de solutions proposées par les fournisseurs. Car, au bout du compte, la configuration ou les modifications de configuration stockées dans le dépôt et déclenchées par un Webhook doivent encore être traduites dans le langage des équipements.
C’est là que la standardisation et les solutions entrent en jeu.
La standardisation réduit la charge liée à l’intégration opérationnelle
L’automatisation est un sujet sur lequel beaucoup d’entre nous chez F5 se concentrent actuellement. L’une des solutions que nous avons mises au point est notre chaîne d’outils d’automatisation F5. Elle comprend F5 Application Services 3 Extension (AS3), F5 Declarative Onboarding (DO), F5 Telemetry Streaming et F5 API Services Gateway. Associés à un référentiel, ces outils permettent aux entreprises de mettre en place le pipeline nécessaire au déploiement des services applicatifs dont une application (et l’entreprise) a besoin pour rester rapide, sécurisée et disponible.
Mais Lori, vous dites-vous, cela ne m’aide pas pour tous les autres appareils et services que je dois automatiser et intégrer.
C’est vrai. C’est l’un des domaines dans lesquels la standardisation autour d’une plateforme commune de services applicatifs peut s’avérer utile. Comme la plateforme (BIG-IP) est la même pour un large éventail de services applicatifs, vous pouvez utiliser la chaîne d’outils d’automatisation pour déployer, entre autres, un WAF, un équilibreur de charge, un contrôle d’accès ainsi qu’une protection contre les attaques DDoS. La standardisation sur un nombre aussi restreint que possible de plateformes apporte une valeur ajoutée en réduisant la charge d’intégration pour toutes les opérations liées au réseau, à l’infrastructure et à la sécurité.
Cela est vrai aussi bien dans le cadre du centre de données que dans un scénario multicloud. La standardisation sur une plateforme unique pour l’ensemble des services applicatifs et des environnements cloud permet d’accélérer la création de valeur lors du déploiement d’applications, où qu’elles se trouvent.
Vous pouvez trouver la chaîne d’outils d’automatisation F5 (entièrement gratuite) à plusieurs endroits :
N’oubliez donc pas que les dépôts ne servent pas uniquement à stocker des éléments. Ils constituent un outil précieux dans votre arsenal d’automatisation, que vous pouvez mettre à profit pour automatiser tous les composants disparates de votre pipeline. La standardisation autour d’un dépôt et d’une plateforme de services applicatifs peut grandement contribuer à réduire la charge opérationnelle imposée par ce mot qui fâche : l’intégration.
*comprenez « PERL » comme Python ou un autre langage de script réellement utilisable. PERL est simplement le seul qui rime avec curl et je n’ai rien trouvé de bien qui rime avec wget.
À 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.