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 distingue les équipes et façonne notre journée de travail, ce sont les limites et l’impact de nos actions, ainsi que les outils dont nous disposons. Les équipes DevOps se concentrent généralement sur une application ou un ensemble de services. Les équipes NetOps couvrent une entreprise, voire des centaines d’entreprises dans le cas des équipes cloud NetOps (oui, elles existent). La plupart des équipes réseau ont toujours un pied dans le monde physique, car il faut bien faire circuler ces photons et électrons d’un point à un autre. La majorité des équipes DevOps évoluent dans le monde virtuel, tirant parti de la puissance de création et suppression de ressources quasi instantanée. Bien que les équipes développement et DevOps abstraient volontiers (et à raison) leur code et leur logique métier des détails techniques de l’architecture sous-jacente, elles font confiance à quelqu’un pour s’assurer que leurs appels API arrivent au bon endroit et en reviennent. Vous souhaitez avancer rapidement sans interruptions, ou pouvoir diagnostiquer et réparer facilement en cas de problème. Les univers dans lesquels évoluent ces équipes présentent simplement des réalités un peu différentes vues 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.