Les décisions concernant le développement, le test, le déploiement, l'exploitation et la maintenance des applications d'entreprise ne sont pas prises dans un silo. Dans le passé, il est possible que le personnel chargé de l'exploitation du réseau ait eu le contrôle, qu'il soit le dernier arrêt avant que quelque chose d'important ne se produise. Et pour être honnête, la plupart d'entre eux aimaient probablement cette façon de faire.
Mais les choses ont changé. Maintenant, plutôt que d'exercer un contrôle strict, les NetOps sont bombardés par des gens (les gens des DevOps, disons-le clairement) qui préfèrent faire les choses par eux-mêmes. Des choses que les NetOps aimeraient qu'ils ne fassent pas (comme contourner les protocoles de sécurité pour votre nouvelle application ou modifier les paramètres de répartition de charge pour cette mise à jour de l'application).
Aujourd'hui, on peut dire que les gens des DevOps essaient simplement d'améliorer les choses. Plus d'adaptation. Plus d'autogestion et moins de microgestion. Plus Agiles (avec un A majuscule).
Le fait est que, dans l'environnement d'entreprise actuel, les DevOps ont besoin des NetOps s'ils veulent conserver leur style de travail Agile. Les DevOps ne peuvent tout simplement pas le faire seuls (toutes ces applications s'exécutent sur une infrastructure sous-jacente, après tout). Et ils ne peuvent pas s'attendre à ce que les NetOps se retirent et abandonnent toutes leurs responsabilités traditionnelles. Et vous ne le voudriez pas non plus. Les NetOps jouent un rôle important dans le maintien de la sécurité et des performances de l'ensemble des applications que créent les DevOps, et ils apportent des compétences et des capacités importantes au flux de travail CI/CD.
Si vous faites partie des DevOps et que vous essayez d'impliquer davantage vos collègues des NetOps dans le flux de travail CI/CD, il faut en premier lieu que ceux-ci veuillent participer, pour voir l'intérêt de changer le statu quo. C'est en fait assez facile à faire, puisque, à portée de main, vous avez les fruits de ce que l'automatisation résout facilement : toutes les tâches fastidieuses, longues 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. Se frayer un chemin à travers une pile d'ordres, saisir manuellement chaque changement, puis vérifier que vous l'avez bien fait parce qu'après tout, c'est votre neuvième ce matin et qu'ils commencent tous à fonctionner ensemble et, pourquoi êtes-vous entré dans ce domaine à la base ? Remplir des ordres de modification toute la journée, tous les jours ? Ça m'étonnerait.
Il existe un meilleur moyen. Celui d'automatiser toutes ces tâches redondantes, souvent répétitives, qui paralysent une journée autrement intéressante et productive.
Près de 42 % des organisations ont déjà automatisé le déploiement de leurs services applicatifs, selon notre rapport sur l'état des services applicatifs.
Les gens du monde des affaires voulaient que nous soyons les premiers à le faire, car tout est dans le produit, n'est-ce pas ? Qui se soucie de savoir si les hommes et les femmes qui le fabriquent aiment leur travail, n'est-ce pas ? (Faux !)
Néanmoins, des performances et une sécurité solides pour vos applications sont en fait un effet secondaire plutôt sympa qui rend votre travail moins péniblement redondant.
La beauté de l'automatisation, c'est que si vous faites bien les choses du premier coup, vous savez qu'elles seront toujours bien faites par la suite.
En automatisant les services qui rendent vos applications fiables et sûres, vous libérez non seulement du temps pour des projets plus intéressants et moins répétitifs, mais vous améliorez également la qualité de ces services. En effet, les flux de travail automatisés et bien conçus n'apparaissent pas comme par enchantement. C'est le rôle de l'ingénieur des NetOps de créer le modèle optimal sur lequel chaque flux de travail automatisé fonctionne, générant à son tour des résultats optimaux encore et encore.
La beauté de l'automatisation, c'est que si vous faites bien les choses du premier coup, vous savez qu'elles seront toujours bien faites par la suite.
Dans un flux de travail automatisé, non seulement les NetOps gardent le contrôle de leurs domaines d'expertise (ce qui rend vos applications plus rapides, plus fiables et plus sûres), mais ils peuvent générer des processus automatisés si simples à utiliser que les DevOps ne se sentiront plus jamais illégitimes (ce qui, encore une fois, rend vos applications plus rapides, plus fiables et plus sûres).
Il est presque toujours vrai que ni l'équipe des DevOps ni celle des NetOps ne sont capables de trouver toutes les solutions nécessaires à la maintenance des applications et des données critiques d'une organisation. Ces deux équipes ont toujours dû travailler ensemble. Et les capacités d'automatisation actuelles contribuent largement à réduire les frictions autour de ces interactions.
DevOps, NetOps, SecOps... Aucune équipe d'exploitation n'est une isolée. Dans le flux de travail moderne des CI/CD, la réussite vient du développement de méthodologies clairement définies et éprouvées qui peuvent être rapidement et facilement (c'est-à-dire automatiquement) reproduites 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, chacune apportant son expertise pour soutenir les autres.
Quel que soit l'environnement (cloud, conteneur, etc.), vos applications reposent sur des services applicatifs, des services réseau et des services de sécurité sous-jacents. Les NetOps ont pour rôle de maintenir la circulation des données sur le réseau, de s'assurer que les applications sont évolutives et réactives, et de veiller à ce que les données soient disponibles en cas de besoin et toujours sécurisées. Et chaque équipe d'exploitation 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 submergé ou du risque que des menaces extérieures tentent d'attaquer vos actifs. Et il est intéressant de noter que les principes des DevOps qui conduisent à de bons résultats pour le développement de logiciels — culture, automatisation, mesure et partage — sont les mêmes principes qui conduisent à de bons résultats en matière de sécurité, selon le Rapport 2019 sur l'état des DevOps par Puppet.
Cette interaction entre les différentes équipes d'exploitation est constante. L'informatique fonctionne sur ce mode à l'ère d'Internet. Mais il y a encore des possibilités d'amélioration, comme lorsque le processus de développement logiciel Agile est arrivé, en accélérant le développement et le déploiement des applications. À cette époque, les DevOps ont commencé à porter le changement vers une approche plus Agile du développement, par une méthode qui recherche le raccourci « du code au client ».
Cette accélération entraîne le changement radical auquel assistent les DevOps actuellement. Le bon côté, c'est que les DevOps sont capables d'aller plus vite et d'être plus proactifs ; et le mauvais côté, c'est qu'il peut engendrer des frictions lorsque les processus des autres départements ne sont pas mis en place pour fonctionner de la même manière.
Le simple fait d'ignorer ces autres départements ou de ne pas tenir compte des collègues qui n'ont pas encore adopté votre nouvelle façon de faire est une mauvaise idée. Lorsque les DevOps essaient de tout faire seuls, c'est à la fois inefficace et inadéquat. C'est ainsi que les processus sont brisés (par inadvertance ou non), et des processus brisés peuvent entraîner toutes sortes de problèmes. Et pas seulement pour les DevOps, mais pour tout le monde, y compris vos clients, qui sont les dernières personnes sur lesquelles vous voulez avoir un impact négatif.
Pour que les DevOps puissent vraiment faire leur travail correctement, les NetOps doivent être vus comme un partenaire, et non comme un ennemi. Et la clé de voûte de tout partenariat solide est la communication. Les DevOps doivent communiquer avec l'équipe réseau pour savoir comment obtenir les services dont vous avez besoin pour soutenir vos applications.
Souvent, l'équipe DevOps est experte en automatisation, dans le cadre général et dans des domaines 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 fournies et des outils disponibles pour cette fourniture. Grâce à la conversation et au respect mutuel, DevOps et NetOps peuvent identifier les domaines dans lesquels 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 des NetOps à étendre le rôle de l'automatisation à l'ensemble du flux de travail CI/CD. La clé est de reconnaître que, tout comme vous êtes experts en développement de code, un ou plusieurs de vos collègues sont des experts en fourniture de services de réseau et de sécurité pour soutenir ce code. Ne manquez pas l'occasion de les aider à être le meilleur expert possible.