Combler le fossé entre le DevOps et le NetOps

Robert HaynesResponsable marketing technique

Au cas où vous ne l’auriez pas remarqué, nous publions une série sur le thème « Combler le fossé entre… »

Cet article porte sur la manière de combler le fossé entre les équipes, ce qui, de prime abord, me semble être un piège.

J’ai vu trop d’articles opposer les équipes DevOps et NetOps, presque sur le plan personnel. Ce n’est pas constructif, car le problème ne vient ni des personnes ni des équipes, mais des contraintes et des attentes qui les ont façonnées. La plupart des membres de ces équipes aiment faire la même chose au travail : des trucs sympas. Nous voulons tous créer quelque chose dont nous sommes fiers, qui soit utile et qui soit, eh bien, sympa.

Ce qui diffère d’une équipe à l’autre, et ce qui façonne notre journée de travail, ce sont le périmètre et les répercussions de nos activités, ainsi que les outils dont nous disposons. Les équipes DevOps répondent généralement aux besoins d’une application ou d’un ensemble de services. Les équipes NetOps, quant à elles, répondent aux besoins d’une entreprise, voire de centaines d’entreprises dans le cas des équipes NetOps cloud (oui, elles existent bel et bien). La plupart des équipes réseau ont au moins un pied dans le monde physique, car il faut bien que quelque chose achemine ces photons et ces électrons d’un endroit à un autre. La plupart des équipes DevOps évoluent dans le monde immatériel du virtuel, où elles bénéficient de la possibilité de créer et de supprimer des ressources presque instantanément. Si les équipes de développement et DevOps font volontiers abstraction — et à juste titre — des détails techniques de l’architecture sous-jacente dans leur code et leur logique métier, c’est parce qu’elles partent implicitement du principe que quelqu’un veille à ce que leurs appels d’API parviennent à la bonne destination et en reviennent. Tout le monde veut avancer vite, tout le monde veut éviter les pannes ou, lorsqu’elles surviennent, pouvoir les diagnostiquer et les corriger facilement. C’est simplement que, vus de l’intérieur, les univers dans lesquels ces équipes évoluent peuvent sembler quelque peu différents.

C’est aux frontières de ces deux réalités que les problèmes peuvent commencer. Il est clair que, dans de nombreuses organisations, il existe un fossé entre les pratiques de travail et les exigences en matière de SLA des différentes équipes. Bien que ces frictions puissent sembler nouvelles, nous les observons depuis bien plus d’une décennie, tout simplement parce que la technologie F5 a toujours assuré l’interconnexion entre les équipes chargées des applications et celles chargées de l’infrastructure. Qu’il s’agisse simplement d’une modification du nombre de serveurs backend ou du comportement de l’application, les changements apportés à l’architecture applicative ont toujours dû être répercutés sur la couche de mise à disposition des applications, où s’effectuent l’inspection de sécurité, le routage du contenu ou l’équilibrage de 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 leurs effets deviennent donc plus manifestes.

C’est pourquoi la période actuelle est si passionnante. Car jamais nous n’avons eu une telle occasion de combler ce fossé. Chez F5, nous développons toujours plus d’outils pour intégrer notre technologie ultra-robuste, de classe entreprise, à des workflows plus agiles et automatisés. Nous proposons des formations à ces nouvelles méthodes de travail à toutes les personnes intéressées. Et nous transformons également notre façon de travailler en interne.

Mais le meilleur moyen de rapprocher des univers différents repose sur la compréhension et le partage d’expériences. Les outils et les processus destinés à soutenir ce rapprochement ne tiendront pas sans le ciment de la collaboration. C’est ce qui m’enthousiasme le plus à l’idée de travailler davantage avec NGINX : pouvoir franchir le fossé et découvrir les choses de leur point de vue et, surtout, de celui de leurs clients, de l’autre côté de cette fracture entre les processus. Ensemble, nous pouvons aider nos clients communs à favoriser une compréhension toujours plus fine entre toutes les équipes impliquées dans la fourniture d’applications sécurisées, rapides et innovantes. Bien sûr, la technologie aura sa place : après tout, c’est ce que nous concevons. Mais elle couvrira un éventail plus large de cas d’usage et s’appuiera sur une vision plus globale du DevOps et du NetOps afin de répondre aux besoins du groupe qui reste au cœur de nos priorités : nos clients et nos utilisateurs.

À propos de l’auteur

Robert HaynesResponsable marketing technique

Autres articles de Robert Haynes