Combler le fossé entre DevOps et NetOps
Au cas où vous ne l’auriez pas remarqué, nous écrivons une série sur le thème « Combler le fossé entre… »
Celui-ci vise à combler le fossé entre les équipes, ce qui me semble au premier abord être un piège.
J’ai vu trop d’articles qui opposent les équipes DevOps et les équipes NetOps les unes aux autres, presque au niveau personnel. Cela n’aide pas, car ce n’est pas une question de personnes ou d’équipes, mais plutôt des contraintes et des attentes qui les ont formées. Les individus au sein de ces équipes aiment tous faire la même chose au travail : des choses sympas. Nous voulons tous créer quelque chose dont nous sommes fiers, qui fasse quelque chose d’utile et qui soit, eh bien, cool.
Ce qui différencie les équipes et ce qui détermine la forme de notre journée de travail, ce sont les limites et les impacts de ce que nous faisons, ainsi que les outils à notre disposition. Les équipes DevOps résolvent généralement les problèmes liés à une application ou à un ensemble de services. Les équipes NetOps résolvent des problèmes pour une entreprise, ou pour des centaines d’entreprises dans le cas des équipes NetOps cloud (oui, elles existent). La plupart des équipes réseau ont au moins un pied dans le monde physique, car quelque chose doit réellement pousser ces photons et ces électrons d’un endroit à un autre. La plupart des équipes DevOps travaillent dans le monde éthéré du virtuel, profitant du pouvoir de création et de destruction quasi instantanée des ressources. Alors que les équipes de développement et DevOps abstraient volontiers (et à juste titre) leur code et leur logique métier des détails de l'architecture sous-jacente, elles le font avec la confiance implicite que quelqu'un s'assure que leurs appels d'API arrivent au bon endroit et en reviennent. Tout le monde veut aller vite, tout le monde veut que les choses ne se cassent pas ou qu’elles soient faciles à diagnostiquer et à réparer lorsqu’elles se cassent. C’est juste que les univers qu’ils habitent peuvent paraître un peu différents de l’intérieur.
C’est aux frontières de ces deux réalités que les ennuis peuvent commencer. Il est clair que, dans de nombreuses organisations, il existe un fossé entre les pratiques de travail et les exigences SLA des différentes équipes. Bien que cette friction puisse être considérée comme une nouveauté, c'est une condition que nous observons depuis plus d'une décennie - simplement parce que la technologie F5 a toujours été l'interconnexion entre les équipes axées sur les application et les équipes axées sur l'infrastructure. Qu'il s'agisse simplement d'un changement dans le nombre de serveurs principaux ou dans le comportement de application , les modifications apportées à l'architecture de l' application ont toujours dû être reflétées dans la couche de diffusion de application , où se produisent l'inspection de sécurité, le routage du contenu ou l'équilibrage de la charge. Maintenant que les développeurs organisent leur flux de travail de manière plus itérative, ces changements se produisent de plus en plus rapidement, et les symptômes deviennent donc plus évidents.
C’est pourquoi c’est une période si excitante. Parce qu’il n’y a jamais eu d’opportunité pareille pour combler ce fossé. Chez F5, nous développons de plus en plus d'outils pour intégrer notre technologie ultra-robuste de classe entreprise à des flux de travail plus agiles et automatisés. Nous avons dispensé des formations sur ces nouvelles méthodes de travail à tous ceux qui le souhaitaient. Et nous avons transformé notre façon de travailler en interne.
Mais le meilleur pont entre les divisions est celui construit à partir de la compréhension et des expériences partagées. Les outils et les processus qui soutiennent le pont ne tiendront pas en place sans le mortier de la collaboration. C'est ce que j'attends le plus de ma collaboration avec NGINX : l'opportunité de combler le fossé et de voir à quoi ressemblent les choses de leur côté et, plus important encore, du côté de leurs clients. En travaillant ensemble, nous pouvons aider les clients communs à favoriser une meilleure compréhension entre toutes les équipes impliquées dans la fourniture applications sécurisées, rapides et innovantes. Bien sûr, il y aura de la technologie là-dedans ; après tout, c’est ce que nous créons. Mais il couvrira une gamme plus large de cas d'utilisation et sera guidé par une vision plus complète autour de DevOps et NetOps pour répondre aux besoins du groupe sur lequel nous nous concentrons le plus : nos clients et nos utilisateurs.