NetOps (presque) à la rencontre de DevOps dans la course à l'automatisation
Il existe une croyance commune selon laquelle dans la course à l’automatisation du pipeline de déploiement (c’est ce que nous appelons la production de nos jours), les NetOps sont loin derrière leurs homologues DevOps.
Cette perception est importante, car le manque d’automatisation – et la volonté de la part de NetOps de le permettre – est souvent cité comme un moteur clé de l’adoption du cloud public. Il est également en partie responsable de l'émergence de technologies telles que les conteneurs qui attirent délibérément de plus en plus de services réseau et d'application dans l'écosystème afin qu'ils puissent être abstraits jusqu'à ce qu'il n'ait plus d'importance qu'ils soient automatisés en production ou non.
La dernière fois que nous avons interrogé ceux qui étaient sur le terrain, nous avons constaté que cette citation était en grande partie vraie. En fait, 65 % des DevOps nous ont dit que le manque d’accès et d’automatisation du pipeline de déploiement était un facteur dans leur volonté de contourner l’informatique pour trouver d’autres solutions, telles que le cloud et les conteneurs.
Mais l’idée selon laquelle NetOps ne fait pas partie de la course à l’automatisation n’est pas tout à fait exacte. En fait, il semble que les NetOps gagnent du terrain sur leurs homologues DevOps.
Considérez ces données potentiellement surprenantes issues d’une enquête récente menée par F5 et RedHat – NetOps Meets DevOps : L'état de l'automatisation des réseaux . Nous avons interrogé des professionnels de DevOps, de NetOps et de la sécurité sur une variété de sujets liés à DevOps et à leurs pratiques en matière d'automatisation. L’une des questions que nous leur avons posées concernait spécifiquement leur utilisation de l’automatisation pour déployer des composants d’infrastructure sur quatre composants clés du pipeline de déploiement (production) :
- Infrastructure des applications . Il s’agit des serveurs, des systèmes, des intergiciels et des plateformes nécessaires à l’exécution des applications.
- Services d'application . Il s’agit de services tels que l’équilibrage de charge et la mise en cache, le routage HTTP et le contrôle d’entrée.
- Réseau . C’est la base de tous les pipelines. Ce sont les fonctions de routage et de commutation dans le réseau dont chaque application et service d'application a besoin.
- Sécurité . Les services de sécurité incluent le WAF et l'identité, le contrôle d'accès et la protection contre les robots.
Nous avons constaté qu’en moyenne, DevOps est en avance sur NetOps dans la course à l’automatisation de ces composants du pipeline de déploiement. Mais nous constatons également que les NetOps ne sont pas si loin derrière. Nous notons en outre que plus un service est éloigné de l’application, moins il est probable que l’automatisation soit utilisée pour déployer ce service.
Cette différence est sans doute encore source de frictions entre les deux groupes. Nous avons constaté que des pourcentages égaux de DevOps (43 %) estiment que les fréquences de déploiement sont « suffisamment bonnes » et « pas assez fréquentes ». Les NetOps étaient également divisés, avec 31 % déclarant que les fréquences de déploiement étaient « suffisamment bonnes » et 30 % estimant que les fréquences ne répondaient pas aux attentes.
C'est bien loin de notre enquête précédente dans laquelle seulement 18 % des NetOps souhaitaient accélérer le rythme des déploiements.
Mais l’automatisation prend du temps – et demande des efforts. Et les défis abondent. Il serait bon que DevOps se rappelle que l’écosystème actuel d’outils et de groupes d’outils est orienté vers les développeurs et l’infrastructure des applications. Il y a eu peu ou pas de mouvement pour nourrir l'écosystème du côté NetOps. Il est difficile d’obtenir une continuité lorsqu’il n’y a pas beaucoup d’intégration pour vous aider à assembler les différents composants du puzzle du pipeline de déploiement.
Et c’est là que le bât blesse. L’une des raisons pour lesquelles DevOps a connu un tel succès est qu’il est principalement composé de développeurs. Des développeurs qui vivent et respirent le code. Ils ont le savoir-faire pour intégrer ce qui doit l’être. NetOps ne dispose pas nécessairement de ces compétences. Le pipeline de déploiement est principalement composé d’appareils et de systèmes qui s’intègrent via des protocoles. Protocoles bien définis, basés sur RFC, qui ne nécessitent pas d'intégration basée sur du code, car ils ont été conçus pour ne pas le faire.
Il s’agit d’un défi totalement nouveau pour les NetOps, un défi pour lequel ils ne sont pas nécessairement préparés – ni compétents – à relever. À savoir, seulement un peu plus d'un tiers (38 %) des DevOps ont cité « l'intégration d'ensembles d'outils entre les fournisseurs/appareils » comme un défi à l'automatisation du réseau. De l’autre côté du mur, près de la moitié (47 %) des NetOps ont noté le manque d’intégration comme un problème, juste derrière le manque de savoir-faire en matière d’automatisation (49 %).
Les données montrent que malgré les défis inhérents à l’automatisation, les NetOps ne sont pas aussi loin derrière que certains le prétendent. Il existe un grand nombre d'opportunités en matière d'automatisation des réseaux pour les NetOps et la sécurité, qui peuvent ainsi s'insérer dans les pipelines continus qui dominent de plus en plus le développement et le déploiement des applications.
Pour plus de détails et d'analyses sur NetOps Meets DevOps : L'état de l'automatisation des réseaux , assurez-vous de récupérer votre exemplaire dès aujourd'hui !