L’automatisation est l’avenir. Le DevOps a depuis longtemps adopté l’idée d’automatiser tout ce qui peut l’être, mais le NetOps comble rapidement son retard en recourant largement à l’automatisation et à l’orchestration dans les processus de production.
Près de la moitié (46 %%) des personnes interrogées dans le cadre de notre enquête « State of Application Delivery 2018 » ont indiqué utiliser au moins « partiellement » l’automatisation en production. Cela inclut le recours systématique à l’automatisation pour les changements majeurs en production (25 %), les changements mineurs en production (26 %) et même la réponse aux incidents (22 %). Plus de la moitié y ont « parfois » recours dans les trois cas.
Cette automatisation est mise en œuvre de différentes manières. Les solutions d’automatisation réseau telles que celles de Cisco et VMware, ainsi qu’OpenStack sont très répandues, tout comme les frameworks et outils tels que Puppet, Chef et les bons vieux scripts Python.
Dire que l’automatisation est bel et bien en train de devenir une réalité n’est pas un euphémisme. Le NetOps est arrivé. Ce n’est pas un exercice.
À première vue, c’est enthousiasmant, mais lorsqu’on examine de plus près ce que cela implique, on constate qu’il existe des difficultés qui ne sont peut-être pas encore apparues au grand jour.
Par exemple, automatiser une modification sur le pare-feu ou le routeur est une chose. L’intégrer à un processus global de déploiement en est une autre (et le terme exact pour désigner cela est « orchestration », au cas où vous vous poseriez la question).
Dès que vous commencez à enchaîner (intégrer) des systèmes et des scripts, vous avez créé l’équivalent d’une « application ». Celle-ci comporte de nombreux éléments interdépendants qui doivent être déployés, gérés, entretenus, mis à niveau, corrigés et couverts par des licences.
Ce n’est pas une tâche de Sisyphe, mais il est probable que l’équipe NetOps ne la prenne pas en considération.
C’est formidable que les développeurs puissent désormais créer un ticket dans ServiceNow afin de déclencher un workflow informatique qui provisionne, configure et facture comme par magie la ressource souhaitée. Mais que se passe-t-il lorsque ServiceNow se bloque ? Ou lorsque l’un des composants de cette chaîne fragile tombe soudainement en panne ? Ou encore lorsque la mise à niveau de l’un des composants rompt l’intégration ?
Si vous fermez les yeux, vous entendrez les développeurs glousser à cette idée, submergés par la Schadenfreude.
L’une des conséquences imprévues de l’automatisation de l’informatique sera que les équipes informatiques auront davantage de logiciels et de systèmes à maintenir. Certains seront critiques et nécessiteront plus d’attention et d’entretien que d’autres.
Tout comme les grandes entreprises comptent des légions de développeurs chargés de la « maintenance » ou du « support », dont la mission consiste simplement à assurer le bon fonctionnement des systèmes logiciels, les services informatiques auront besoin d’un rôle similaire pour gérer les activités quotidiennes des opérations NetOps.
NetOpsOps. Oui, c’est un affreux mot-valise, mais il décrit bien ce dont nous aurons besoin à mesure que l’automatisation prendra en charge une part croissante des tâches de déploiement NetOps.
Certaines de ces tâches seront d’une nature telle (intégration, systèmes logiciels, etc.) qu’elles pourront être prises en charge par le personnel d’exploitation existant. Mais d’autres seront propres au réseau, ce qui nécessitera une personne qui comprenne à la fois les scripts et les systèmes et les composants réseau concernés.
Vous ne pouvez pas dépanner, mettre à jour ou modifier du code, des scripts ou des modèles si vous ne savez pas ce qu’ils font.
Si vous me demandez ce qui ne va pas avec ma motoneige, je vais vous répondre que je n’en ai aucune idée. Je sais ouvrir le capot et recharger la batterie, mais ne me demandez pas de bricoler les pièces qui la font avancer. C’est comme demander à un stagiaire en développement maîtrisant JavaScript de mettre à jour un copybook COBOL. C’est la catastrophe assurée.
À terme, l’équipe NetOps aura besoin de personnes (les opérateurs NetOps) qui connaissent bien le réseau et les systèmes utilisés pour l’automatiser. Plus l’automatisation sera utilisée, plus il sera indispensable de disposer de telles personnes pour assurer sa maintenance pendant que les ingénieurs travailleront sur la prochaine grande innovation.
À 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.