Preenchimento de lacunas entre DevOps e NetOps

Caso você não tenha notado, estamos escrevendo uma série no estilo “Diminuindo a Divisão entre…”

Este é sobre diminuir a distância entre as equipes, o que inicialmente me parece uma armadilha.

Tenho visto muitos artigos que colocam equipes de DevOps e equipes de NetOps em oposição umas às outras, quase no nível pessoal. Isso não ajuda, porque não se trata das pessoas ou das equipes, mas sim das restrições e expectativas que as formaram. Os indivíduos dentro dessas equipes, em sua maioria, gostam de fazer a mesma coisa no trabalho: coisas legais. Todos nós queremos fazer algo de que nos orgulhamos, que faça algo útil e que seja, bem, legal.

O que é diferente entre as equipes e o que determina o formato do nosso dia de trabalho são os limites e os impactos do que fazemos e as ferramentas à nossa disposição. As equipes de DevOps geralmente resolvem problemas de um aplicativo ou de um conjunto de serviços. As equipes de NetOps atendem a uma empresa ou a centenas de empresas no caso de equipes de NetOps na nuvem (sim, elas existem). A maioria das equipes de rede tem pelo menos um pé no mundo físico, porque algo realmente precisa empurrar esses fótons e elétrons de um lugar para outro. A maioria das equipes de DevOps trabalha no mundo etéreo do virtual, aproveitando o poder da criação e destruição quase instantâneas de recursos. Embora as equipes de desenvolvimento e DevOps alegremente (e com razão) abstraiam seu código e lógica de negócios dos detalhes da arquitetura subjacente, elas fazem isso com a confiança implícita de que alguém está garantindo que suas chamadas de API cheguem e saiam do lugar certo. Todo mundo quer se mover rápido, todo mundo quer que as coisas não quebrem ou que sejam fáceis de diagnosticar e consertar quando isso acontecer. Acontece que os universos que eles habitam podem parecer um pouco diferentes por dentro.

É nos limites dessas duas realidades que o problema pode começar. Está claro que, em muitas organizações, há uma divisão entre as práticas de trabalho e os requisitos de SLA de diferentes equipes. Embora esse atrito possa ser considerado algo novo, é uma condição que observamos há mais de uma década, simplesmente porque a tecnologia F5 sempre foi a interconexão entre equipes focadas em aplicativos e equipes focadas em infraestrutura. Seja apenas uma mudança no número de servidores de back-end ou no comportamento do aplicativo, as mudanças na arquitetura do aplicativo sempre precisaram ser refletidas na camada de entrega do aplicativo, onde a inspeção de segurança, o roteamento de conteúdo ou o balanceamento de carga acontecem. Agora que os desenvolvedores estão organizando seu fluxo de trabalho para ser mais iterativo, essas mudanças estão acontecendo cada vez mais rápido e, portanto, os sintomas estão se tornando mais óbvios.

É por isso que é um momento tão emocionante. Porque nunca houve uma oportunidade como esta para diminuir essa divisão. Na F5, desenvolvemos cada vez mais ferramentas para conectar nossa tecnologia hiper-robusta de nível empresarial a fluxos de trabalho mais ágeis e automatizados. Estamos oferecendo treinamento sobre essas novas formas de trabalho para qualquer um que queira. E estamos transformando a maneira como trabalhamos internamente.

Mas a melhor ponte entre as divisões é construída a partir da compreensão e das experiências compartilhadas. As ferramentas e os processos para dar suporte à ponte não se manterão sem a base da colaboração. É isso que mais espero ao trabalhar mais com a NGINX : a oportunidade de superar as barreiras e ver como as coisas são do lado deles e, mais importante, do lado dos clientes em relação ao processo. Trabalhando juntos, podemos ajudar clientes em comum a promover um entendimento cada vez melhor entre todas as equipes envolvidas no fornecimento de aplicativos seguros, rápidos e inovadores. Claro, haverá tecnologia ali; afinal, é o que fazemos. Mas ele cobrirá uma gama mais ampla de casos de uso e será orientado por uma visão mais completa em torno de DevOps e NetOps para atender às necessidades do grupo em que mais nos concentramos: nossos clientes e usuários.