Caso você ainda não tenha percebido, estamos escrevendo uma série nos moldes de “Diminuindo a distância entre…”
Este texto é sobre como superar a divisão entre equipes, o que, a princípio, me parece uma armadilha.
Já vi artigos demais colocando as equipes de DevOps e NetOps umas contra as outras, quase no âmbito pessoal. Isso não ajuda — porque a questão não são as pessoas nem as equipes, mas as limitações e expectativas que as moldaram. Em sua maioria, as pessoas dessas equipes gostam de fazer a mesma coisa no trabalho: coisas legais. Todos queremos criar algo de que possamos nos orgulhar, que seja útil e que seja, bem, legal.
O que difere entre as equipes — e determina como é o nosso dia de trabalho — são os limites e os impactos do que fazemos, além das ferramentas à nossa disposição. Em geral, as equipes de DevOps buscam soluções para uma aplicação ou um conjunto de serviços. Já as equipes de NetOps buscam soluções para uma empresa — ou para centenas delas, no caso das equipes de NetOps em nuvem (sim, elas existem). A maioria das equipes de rede mantém pelo menos um pé no mundo físico, pois algo precisa efetivamente transportar 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 a possibilidade de criar e destruir recursos quase instantaneamente. Embora as equipes de desenvolvimento e DevOps abstraiam, com satisfação (e toda a razão), seu código e sua lógica de negócios dos detalhes da arquitetura subjacente, elas fazem isso confiando implicitamente que alguém está garantindo que suas chamadas de API cheguem ao destino certo e retornem corretamente. Todos querem avançar com rapidez; todos querem evitar falhas ou, quando elas ocorrerem, que sejam fáceis de diagnosticar e corrigir. A questão é apenas que, vistos de dentro, os universos que essas equipes habitam podem parecer um pouco diferentes.
É nos limites entre essas duas realidades que os problemas podem começar. Está claro que, em muitas organizações, existe uma divisão entre as práticas de trabalho e os requisitos de SLA das diferentes equipes. Embora esse atrito possa ser considerado algo novo, trata-se de uma situação que observamos há bem mais de uma década — simplesmente porque a tecnologia da F5 sempre serviu de interconexão entre as equipes focadas em aplicações e as equipes focadas em infraestrutura. Seja apenas uma mudança no número de servidores de backend ou no comportamento da aplicação, as alterações na arquitetura da aplicação sempre precisaram ser refletidas na camada de entrega de aplicações, onde ocorrem a inspeção de segurança, o roteamento de conteúdo ou o balanceamento de carga. Agora que os desenvolvedores estão organizando seu fluxo de trabalho de forma mais iterativa, essas mudanças estão acontecendo cada vez mais rápido e, por isso, os sintomas estão se tornando mais evidentes.
É por isso que este é um momento tão empolgante. Nunca houve uma oportunidade como esta para superar essa divisão. Na F5, temos desenvolvido cada vez mais ferramentas para integrar nossa tecnologia extremamente robusta e de nível empresarial a fluxos de trabalho mais ágeis e automatizados. Temos oferecido treinamento sobre essas novas formas de trabalhar a todos os interessados. E temos transformado a maneira como trabalhamos internamente.
Mas a melhor ponte entre realidades distintas é construída com compreensão e experiências compartilhadas. As ferramentas e os processos que sustentam essa ponte não se manterão firmes sem a argamassa da colaboração. É isso que mais me entusiasma em trabalhar mais com a NGINX — a oportunidade de transpor essa lacuna e enxergar as coisas pela perspectiva deles e, mais importante, pela perspectiva dos clientes deles diante dessa divisão entre processos. Trabalhando juntos, podemos ajudar nossos clientes em comum a promover uma compreensão cada vez maior entre todas as equipes envolvidas na entrega de aplicações seguras, rápidas e inovadoras. É claro que haverá tecnologia nisso tudo; afinal, é o que desenvolvemos. Mas ela abrangerá uma variedade maior de casos de uso e será orientada por uma visão mais completa de DevOps e NetOps, para atender às necessidades do grupo que está no centro de nossas atenções: nossos clientes e usuários.
Sobre o autor
Publicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...