Les décisions concernant le développement, les tests, le déploiement, l’exploitation et la maintenance des applications d’entreprise ne sont pas prises de manière isolée. Autrefois, c'était peut-être le personnel d'exploitation du réseau qui avait le contrôle, qui était la dernière étape avant que quoi que ce soit d'important ne puisse se produire. Et pour être honnête, la plupart d’entre eux ont probablement aimé ça de cette façon.
Mais les choses ont changé. Désormais, plutôt que d’exercer un contrôle strict, NetOps est bombardé de personnes (des personnes DevOps, pour être honnête) qui préfèrent faire les choses par elles-mêmes. Des choses que NetOps souhaite que vous ne fassiez pas (comme contourner les protocoles de sécurité pour votre nouvelle application ou modifier les paramètres d'équilibrage de charge pour cette mise à jour d'application).
Aujourd’hui, on peut dire que les gens de DevOps essaient simplement d’améliorer les choses. Plus adaptable. Plus autogéré et moins micro-géré. Plus Agile (avec un grand A).
Le fait est que, dans l’environnement d’entreprise actuel, DevOps a besoin de NetOps s’il veut conserver son style de travail Agile. DevOps ne peut tout simplement pas le faire seul (après tout, toutes ces applications s’exécutent sur une infrastructure sous-jacente). Et ils ne peuvent pas s’attendre à ce que NetOps passe au second plan et renonce à toutes ses responsabilités traditionnelles. Et vous ne le voudriez pas non plus. NetOps joue un rôle important dans le maintien de la sécurité et des performances de toutes les applications créées par DevOps, et ils apportent des compétences et des capacités importantes au flux de travail CI/CD.
Si vous travaillez dans DevOps et que vous essayez d’impliquer davantage vos collègues NetOps dans le flux de travail CI/CD, vous devez d’abord leur donner envie de participer, de voir l’intérêt de changer le statu quo. C'est en fait assez facile à faire, étant donné que les tâches faciles à réaliser et que l'automatisation résout facilement sont toutes les tâches fastidieuses, chronophages et routinières qui doivent être effectuées encore et encore. Le genre de tâches que tout travailleur sain d’esprit serait heureux de confier à un robot.
Les ordres de modification en sont un bon exemple. Vous parcourez une pile de commandes, saisissez manuellement chaque modification, puis vérifiez à nouveau que vous l'avez fait correctement, car après tout, c'est votre neuvième commande ce matin et elles commencent toutes à coïncider. Et pourquoi vous êtes-vous lancé dans ce domaine en premier lieu ? Remplir des bons de commande toute la journée, tous les jours ? Je ne pense pas.
Il existe une meilleure solution. Et cela consiste à automatiser au maximum toutes ces tâches redondantes et souvent répétitives qui ralentissent une journée autrement intéressante et productive.
Les gens de l’entreprise voulaient que nous commencions par celui-ci, parce que c’est le produit qui compte, n’est-ce pas ? Qui se soucie de savoir si les hommes et les femmes qui y parviennent aiment leur travail, n’est-ce pas ? (Faux!)
Néanmoins, des performances et une sécurité robustes pour vos applications constituent en réalité un effet secondaire plutôt intéressant pour que votre travail soit moins redondant et ennuyant.
En automatisant les services qui rendent vos applications fiables et sécurisées, non seulement vous libérez du temps pour des projets plus intéressants et moins répétitifs, mais vous améliorez également la qualité de ces services. C’est parce que les flux de travail automatisés et bien conçus ne se créent pas d’eux-mêmes. Le rôle de l’ingénieur NetOps est de créer le modèle optimal sur lequel fonctionne chaque flux de travail automatisé, générant ainsi des résultats optimaux encore et encore.
La beauté de l’automatisation est que si vous le faites correctement la première fois, vous savez que ce sera également le cas à chaque fois par la suite.
Dans un flux de travail automatisé, non seulement NetOps peut conserver le contrôle de ses domaines d'expertise (ce qui rend vos applications plus rapides, plus fiables et plus sécurisées), mais il peut également générer des processus automatisés si simples à utiliser que DevOps n'envisagera plus jamais de devenir un escroc (ce qui, encore une fois, rend vos applications plus rapides, plus fiables et plus sécurisées).
Il arrive presque toujours que ni les équipes DevOps ni les équipes NetOps ne soient capables de déterminer seules toutes les solutions impliquées dans la maintenance des applications et des données critiques d’une organisation. Il a toujours été nécessaire que ces deux équipes travaillent ensemble. Et les capacités d’automatisation d’aujourd’hui contribuent grandement à réduire les frictions autour de ces interactions.
DevOps, NetOps, SecOps… aucun Ops n’est une île. Dans le flux de travail CI/CD moderne, le succès passe par le développement de méthodologies clairement définies et éprouvées qui peuvent être rapidement et facilement (c'est-à-dire automatiquement) répliquées dans des systèmes complexes. La création de bases solides pour ces flux de travail automatisés nécessite un partenariat solide entre DevOps, NetOps et SecOps, chacun apportant son expertise en soutien aux autres.
Quel que soit l'environnement (cloud, conteneur, etc.), vos applications s'appuient sur des services applicatifs sous-jacents, des services réseau et des services de sécurité. NetOps a pour rôle de maintenir la circulation des données sur le réseau, de garantir l'évolutivité et la réactivité des applications et de garantir que les données sont disponibles en cas de besoin et toujours sécurisées. Et chaque équipe d’opérations a un rôle à jouer dans la réduction des risques, qu’il s’agisse du risque que votre application ne fonctionne pas comme prévu, du risque que votre réseau soit surchargé ou du risque que des menaces extérieures tentent d’attaquer vos actifs. Il est intéressant de noter que les principes DevOps qui génèrent de bons résultats en matière de développement logiciel (culture, automatisation, mesure et partage) sont les mêmes principes qui génèrent de bons résultats en matière de sécurité, selon le rapport 2019 State of DevOps de Puppet .
Cette interaction entre les différentes équipes Ops est constante. C’est ainsi que l’informatique a fonctionné tout au long de l’ère Internet. Mais il y a toujours place à l’amélioration, comme lorsque le processus de développement logiciel Agile est apparu, repoussant les limites de la rapidité avec laquelle les applications pouvaient être développées et déployées. À cette époque, DevOps a commencé à opérer un grand changement vers une approche plus Agile du développement, en adoptant un moyen plus rapide de passer « du code au client ».
Cette augmentation de la vitesse est à l’origine du changement radical auquel DevOps est aujourd’hui confronté. Cela a un bon côté, dans la mesure où DevOps permet d’avancer plus rapidement et d’être plus proactif ; mais cela a aussi un mauvais côté, dans la mesure où cela peut créer des frictions lorsque les processus des autres départements ne sont pas configurés pour fonctionner de la même manière.
Ignorer simplement les autres services ou négliger les collègues qui n’ont pas encore tout à fait adopté votre nouvelle façon de faire est une mauvaise idée. Lorsque DevOps essaie de tout faire lui-même, c’est à la fois inefficace et inadéquat. C’est ainsi que les processus sont interrompus (par inadvertance ou non), et des processus interrompus peuvent entraîner toutes sortes de problèmes. Et pas seulement pour DevOps, mais pour tout le monde, y compris vos clients, qui sont les dernières personnes sur lesquelles vous souhaitez avoir un impact négatif.
Pour que DevOps fasse vraiment son travail correctement, vous avez besoin de NetOps comme partenaire, pas comme ennemi. Et la clé de voûte de tout partenariat solide est la communication. DevOps doit communiquer avec l’équipe réseau sur la manière d’obtenir les services dont vous avez besoin pour prendre en charge vos applications.
Souvent, l'équipe DevOps sera experte en automatisation, dans le cadre global et dans des éléments tels que l'infrastructure en tant que code ; mais l'équipe réseau est experte dans la compréhension des ressources architecturales réelles qui doivent être provisionnées et des outils disponibles pour ce provisionnement. Grâce à la conversation et au respect mutuel, DevOps et NetOps peuvent identifier où l’automatisation est nécessaire et la meilleure façon de la réaliser.
Vous n’avez rien à perdre, DevOps, et beaucoup à gagner en aidant vos homologues NetOps à étendre le rôle de l’automatisation dans l’ensemble du flux de travail CI/CD. La clé est de reconnaître que, tout comme vous êtes l’expert en développement de code, un ou plusieurs de vos collègues sont des experts en provisionnement de services réseau et de sécurité pour prendre en charge ce code. Ne manquez pas l’occasion de les aider à devenir le meilleur expert possible.