Hoje em dia, temos muita dificuldade em definir o DevOps porque o problema que ele resolve inicialmente já se foi.

Para algumas empresas recentes, o problema nunca existiu! Eles estão fazendo tudo corretamente, mas, em vez disso, o cenário da engenharia de software evoluiu tão rapidamente que a lacuna foi preenchida por ferramentas e engenharia em nuvem.

Estamos longe dos dias originais do DevOps e de sua mudança cultural com o objetivo de quebrar os silos entre Dev e Ops.

Os silos de desenvolvimento e operações

Em 2008, quando Patrick Dubois Quando pensei pela primeira vez sobre DevOps, ele estava observando a colaboração ineficaz entre desenvolvimento e operações em um contexto onde o gerenciamento de projetos havia acabado de passar de cascata para Agile.

As equipes de operação da época gerenciavam tudo, desde redes, servidores, máquinas virtuais, sistema operacional e atualizações de software. Isso efetivamente escondeu muitas operações manuais. Nem tudo era manual, mas foi antes do Puppet, Chef e Ansible - ou mesmo do Terraform existirem.

Gerenciar versões de servidores e software não era nada simples e exigia muita experiência. Algo que impediria a entrega rápida e confiável de novos lançamentos de software.

A nuvem, o primeiro sinal do desaparecimento de silos

A AWS, nascida em 2006, foi o primeiro grande provedor de nuvem. O DevOps foi cunhado em 2008 e não tinha como objetivo resolver um problema de gerenciamento de nuvem, mas sim os verdadeiros silos entre a operação da infraestrutura local. Esta é a raiz da confusão sobre o que é DevOps. Duas grandes mudanças no cenário da engenharia de software começaram na mesma época.

Quando se trata de computação em nuvem, usamos três modelos principais: Software como Serviço (SaaS), Plataforma como Serviço (PaaS) e Infraestrutura como Serviço (IaaS). Como temos usado essas construções de alto nível, o OPS (administração de sistemas) quase desapareceu. É como se o problema cultural original identificado pelos pais do DevOps não existisse mais.

Cada modelo oferece diferentes níveis de controle, flexibilidade e gerenciamento da infraestrutura subjacente, e muito poucas empresas manteriam a infraestrutura local.

Assim, enquanto o movimento DevOps tentava resolver os problemas de “silotes” entre Dev e Ops , a infraestrutura em nuvem já estava desaparecendo parte do problema ao tornar o Ops obsoleto .

Sem operações, sem silos

As principais motos do DevOps são “deslocar para a esquerda” e “você constrói, você executa”, o que só pode levar à transferência do que era(s) uma(s) tarefa(s) de Ops para os Devs. A nuvem reduziu a necessidade de administradores de sistema (Ops) ao oferecer o modelo IaaS, diminuindo o esforço dos próprios desenvolvedores para gerenciar e implantar aplicativos.

Podemos reformular para que soe melhor! As operações estavam capacitando os desenvolvedores, oferecendo ferramentas para simplificar a integração e implantação de software, reduzindo assim o trabalho pesado exigido pelas equipes de operação para manter a infraestrutura. Como resultado, acabamos em uma situação em que não precisávamos de administração de sistema (Ops).

No entanto, precisamos de alguém para manter essas “ferramentas para simplificar a integração e implantação de software”.

Essa nova função emergente ainda não tem nome, pois foi trazida a você pelo antigo Ops, que a rebatizou como “caras do DevOps”. Vamos chamá-lo de engenheiro DevOps. Alguém provavelmente disse isso em algum momento, e pegou.

DevOps se redefiniu

DevOps nunca foi uma questão de ferramentas; era sobre cultura. A ideia é que a engenharia de software também possa se tornar mais “Lean” e que a entrega de software possa ser feita na hora certa. O problema inicial do DevOps pode já ter desaparecido, mas deu origem à ideia mais importante na engenharia de software: Entrega Contínua.

Há muito que apoio aqueles que afirmam que DevOps não é uma função ou uma equipe e, se você chama assim, está fazendo errado. Mais tarde, percebi que, bem, as coisas eram mais complexas. Incongruentemente, criamos uma função, “o(s) cara(s) que mantém ferramentas para simplificar a integração e implantação de software”, mas não tínhamos um nome para ela.

Pensando bem, você realmente precisa “do(s) cara(s) que mantém ferramentas para simplificar a integração e implantação de software” se tudo fosse uma oferta de nuvem? Totalmente gerenciado? Funciona com o clique de um botão?

Este é o sonho da maioria dos provedores de nuvem e de muitos produtos DevOps SaaS (pense no GitLab, por exemplo). A verdade não é tão simples. Embora, em teoria, as coisas pudessem ter sido simples e as tarefas operacionais poderiam ter sido automatizadas, o serviço totalmente gerenciado, etc. Na realidade, criamos um monstro.

Como resultado, o desafio para a maioria das equipes de operação/infraestrutura (também conhecidas como Ops) é navegar no mapa de inúmeras ferramentas e serviços, compreender, implantar e conectar essas ferramentas em uma infraestrutura e ferramentas coerentes que os desenvolvedores possam usar.

DevOps travado é a palavra-chave, fácil de derivar: DevSecOps, FinOps, GitOps, MlOps, etc.

Mas se você notar, o cheiroso que fica é sempre Ops. O engraçado é que cada abordagem visa remover os Ops das equações. The Ops, também conhecido como “o(s) cara(s) que faz login no sistema e faz coisas para fazê-lo funcionar”.

DR

O problema original que o DevOps pretendia resolver pode não existir mais devido ao surgimento da infraestrutura em nuvem. No entanto, o DevOps deu origem à importante ideia de entrega contínua e trouxe uma mudança cultural na engenharia de software.

Embora o termo “DevOps” possa ter permanecido como uma palavra da moda, ele levou ao desenvolvimento de novas abordagens, como DevSecOps, FinOps e GitOps, todas com o objetivo de eliminar a necessidade de tarefas tradicionais de operações.

Em última análise, o cenário do DevOps e da infraestrutura em nuvem evolui constantemente e é difícil manter-se atualizado e selecionar as ferramentas certas. Ironicamente, DevOps inicialmente significava colaboração entre Dev e Ops, mas mudou no sentido de excluir Ops da equação.