En tant que touche-à-tout de l’informatique, passionné autant par les langages de programmation que par les protocoles et les captures réseau, je suis ravi de voir s’estomper les frontières entre ces deux domaines, comme l’exigent l’automatisation et l’orchestration.
Depuis quatre ans, nous suivons la manière dont les répondants à notre enquête « State of Application Delivery » perçoivent les infrastructures compatibles avec les API et les technologies associées. Au cours de cette période, le pourcentage de personnes qui considèrent la programmabilité des infrastructures comme importante (avec une note de 4 ou 5 sur une échelle de 5) a presque doublé. En 2015, moins de la moitié des répondants — 40 % — nous indiquaient qu’elle était importante. Cette année, ce chiffre atteint le niveau impressionnant de 74 %.
Nous n’aurions peut-être pas dû être surpris par ce constat, au vu des résultats d’une enquête que nous avions menée sur le sujet en 2017. Dans cette étude sur la perception du DevOps et du NetOps, les deux groupes s’accordaient unanimement sur l’importance de l’automatisation du pipeline de production.
Mais les perceptions ne sont que des opinions. L’usage réel, lui, est une tout autre affaire.
L’enquête de cette année révèle que l’automatisation est omniprésente, quels que soient la région, le secteur d’activité et la taille de l’organisation. Même si personne n’a atteint les 100 % (et n’y parviendra probablement jamais), l’automatisation est bien plus présente en production qu’on ne le pensait.
En fait, 25 % des personnes interrogées nous ont indiqué qu’elles utilisaient toujours l’automatisation pour apporter des modifications majeures en production. 60 % utilisent parfois l’automatisation pour apporter des modifications mineures en production. Globalement, l’automatisation était d’ailleurs plus souvent utilisée pour les changements en production que pour la réponse aux incidents. Plus d’une personne sur quatre (26 %) a déclaré ne jamais utiliser l’automatisation pour répondre aux incidents, et seulement 22 % nous ont indiqué qu’elles le faisaient toujours . Cela n’a rien de surprenant, compte tenu de la variabilité inhérente à la gestion d’événements probablement imprévisibles. L’automatisation repose en partie sur un ensemble clairement défini de tâches et d’étapes qui les articulent au sein d’un processus opérationnel. Les changements en production, qu’ils soient majeurs ou mineurs, se prêtent donc mieux à la codification de ces processus. La réponse aux incidents ? Beaucoup moins.
Il semble qu’un très grand nombre de processus soient automatisés dans les centres de données, quels que soient leur taille, leur configuration et leur secteur d’activité.
Vous vous demandez peut-être ce qu’ils utilisent pour mettre en œuvre toute cette automatisation. Par le passé, nous regroupions dans une même question de nombreux outils, ensembles d’outils et frameworks. Mais cette approche n’est plus pertinente à mesure que l’automatisation s’impose réellement, car il faut bien en comprendre les différents aspects pour saisir ce qui se passe :
1. Langages et ensembles d’outils. C’est ce que les équipes NetOps et informatiques utilisent pour piloter et contrôler l’automatisation. Cela comprend des outils comme Ansible (20 %) et Vagrant (5 %), ainsi que des frameworks comme Puppet (19 %) et Chef (16 %). Parmi eux, les bons vieux scripts Python arrivent largement en tête, 39 % des personnes interrogées choisissant de développer leurs propres scripts pour automatiser l’informatique.
2. Automatisation des réseaux. Avec une moyenne de 16 services applicatifs différents présents dans le chemin de données et nécessitant un déploiement, une configuration et une gestion continue afin d’assurer la distribution sécurisée et la mise à l’échelle des applications, la plupart des organisations vont se tourner vers des systèmes tels que Cisco ACI (48 %), VMware (65 %) et OpenStack (26 %). Tous trois ont enregistré des progrès considérables d’une année sur l’autre. Rien d’étonnant dans un contexte où 55 % des organisations se tournent vers l’automatisation et l’orchestration dans le cadre de leurs initiatives de transformation numérique.
3. Environnements d’orchestration de conteneurs (COE). Ces technologies émergentes continuent de faire parler d’elles, et il semble évident que leur utilisation pour faire évoluer les applications conteneurisées est inévitable. Parmi les solutions sur lesquelles nous les avons interrogés, Docker Swarm arrive en tête avec 27 % des répondants, suivi de Red Hat OpenShift avec 21 %, tandis que Kubernetes se classe en troisième position avec un solide score de 16 %. Seuls 48 % nous ont indiqué ne pas utiliser de solution de ce type à l’heure actuelle.
Sans surprise à mes yeux, le nombre de ces outils et frameworks utilisés au sein de chaque organisation diminue. Cela signifie que nous assistons à une utilisation réfléchie des outils et des suites d’automatisation, dans le cadre de ce qui constitue manifestement une démarche stratégique de standardisation. Mieux vaut agir au plus vite, avant que le chaos ne s’installe et que les services informatiques ne ploient sous le poids d’une dette technique et architecturale semblable à celle contre laquelle les développeurs d’applications luttent depuis des années. De fait, 50 % des personnes interrogées n’utilisent qu’un seul framework d’automatisation réseau. Parmi elles, 8 % s’appuient sur Cisco ACI, 5 % sur Open Stack et 19 % sur VMware.
Ce marché reste très mouvant et en constante évolution — si tant est que l’on puisse parler de marché plutôt que de mouvement. L’arrivée massive des approches DevOps en production et la pression exercée par les métiers poussent l’informatique à accélérer. Les équipes NetOps adoptent pleinement l’automatisation et tout ce qu’elle implique. Nous nous attendons à une utilisation accrue de l’automatisation à mesure que l’informatique poursuit sa transformation numérique, afin de fournir aux métiers une base numérique solide sur laquelle développer de nouvelles applications et explorer de nouvelles opportunités.
Pour en savoir plus sur la transformation numérique, le multicloud, les services applicatifs, la sécurité et la transformation continue des NetOps, n’hésitez pas à télécharger votre propre exemplaire de notre rapport 2018 sur l’état de la fourniture d’applications et à suivre les échanges sur Twitter via @f5networks et/ou le hashtag #soad18. Et restez à l’écoute : nous publierons prochainement d’autres analyses (notamment des données et des points de vue qui ne figurent pas dans le rapport) sur notre blog.
À 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.