Um elogio fúnebre ao DevOps

O conceito e a história do DevOps

• DevOps é um conceito introduzido por volta de 2007, com o objetivo de eliminar a separação entre quem gerencia o hardware e quem escreve o software
• No início, foi uma tentativa de imitar procedimentos e ideias da NASA para aumentar a segurança das implantações de código
• Na época, o processo de implantação de software era o seguinte:
  • A equipe de desenvolvimento preparava um release do software de servidor, a equipe de QA testava e depois ele era implantado para o cliente
  • A equipe de operações recebia um playbook com as mudanças no software e como reagir em caso de problemas
  • As atualizações eram liberadas gradualmente dentro do data center, com monitoramento
  • Definia-se um dia de implantação e depois vinha o monitoramento pós-implantação

Os problemas do DevOps

• DevOps era extremamente intensivo em mão de obra
• Exigia colaboração entre equipe de desenvolvimento, equipe de QA, redatores técnicos e equipe de operações
• A entrega de funcionalidades era lenta, e as atualizações mais importantes eram priorizadas
• Muitas organizações adotaram DevOps pelos seguintes motivos:
  • Não era fácil substituir profissionais técnicos
  • Contratar era difícil e caro
  • Fornecedores SaaS reduziram a complexidade
  • Destacavam as vantagens das plataformas de nuvem
  • Os desenvolvedores estavam insatisfeitos com o longo tempo até pequenas mudanças serem implantadas

Como o DevOps ficou na prática

• DevOps tinha como objetivo integrar equipes de desenvolvimento e operações em um único time
• A equipe de QA foi dispensada, e o período de testes internos foi reduzido com implantações rápidas e feedback
• DevOps às vezes é confundido com o SRE do Google, mas SRE adota uma abordagem mais estruturada e rigorosa
• O processo real do DevOps era o seguinte:
  • O desenvolvedor cria uma branch no git e adiciona a funcionalidade
  • Abre um PR, um colega revisa e faz o merge na main
  • O sistema de CI/CD inicia o build e faz push do contêiner para o registry
  • O sistema de CD informa os servidores sobre o novo release e monitora se a implantação foi bem-sucedida
  • Mudanças após a implantação são monitoradas por meio de métricas de percepção do release

Fatores de fracasso do DevOps

• Os desenvolvedores testavam no ambiente local e implantavam em servidores Linux, o que gerava pequenas diferenças
• Como a equipe de operações não monitorava a implantação, era difícil resolver problemas
• Os desenvolvedores tinham pouco conhecimento sobre operação de sistemas
• A introdução de contêineres resolveu parte dos problemas, mas a complexidade operacional continuou existindo

A introdução dos contêineres e seus limites

• Os contêineres resolveram o problema do "na minha máquina funciona"
• Simplificaram os componentes de configuração de servidores Linux
• Problemas que ainda permaneciam
  • Operar: manutenção de infraestrutura, upgrades etc., exigindo especialização
  • Observar: dificuldade para construir e gerenciar sistemas complexos de monitoramento
  • Feedback contínuo: tratamento insuficiente do feedback interno
  • Descobrir: falta de compartilhamento de conhecimento entre equipes
  • Planejar: dificuldade para estabelecer planejamento centralizado

O surgimento da Platform Engineering

• Platform Engineering surgiu como conceito sucessor do DevOps: em vez de a equipe de desenvolvimento entender a operação da plataforma e resolver problemas, isso passa a ser responsabilidade da equipe de plataforma
• Essa abordagem separa com mais clareza as responsabilidades entre desenvolvimento e operação da plataforma, deixando a divisão de papéis mais explícita, mas ainda exige muitas competências técnicas
• Tanto os desenvolvedores quanto a equipe de operações precisam fazer mais trabalho

Conclusão

• Está crescendo a tendência de buscar ferramentas simples e não dependentes de plataforma no espaço de infraestrutura
• Muitas organizações estão abandonando tecnologias complexas como Kubernetes e voltando a workflows mais simples
• Platform Engineering não é uma solução mágica, e as organizações precisam distinguir o que realmente é necessário do que é desnecessário
• É preciso manter as vantagens da abordagem DevOps, mas com foco em simplificação e estabilidade

Opinião do GN⁺

1. A evolução do DevOps e sua situação atual mostram bem a mudança de tendências na indústria de tecnologia. É interessante observar o processo de reconhecer a distância entre os objetivos idealizados do início e a realidade, e buscar uma abordagem mais prática

2. A transição para Platform Engineering parece ser uma tentativa de reconhecer os limites do DevOps e buscar uma nova solução. Ainda assim, isso também não é uma solução perfeita, e será necessário um enfoque sob medida para o porte e as características de cada organização

3. Com o aumento da complexidade das tecnologias cloud native e das arquiteturas de microsserviços, está havendo uma reavaliação da simplicidade e da estabilidade. Isso sugere que, na escolha de tecnologias, o valor de negócio e a eficiência operacional devem ser considerados com ainda mais importância

4. As mudanças em DevOps e Platform Engineering reforçam a importância do aprendizado contínuo e da adaptação nas áreas de desenvolvimento e operações de software. Os profissionais precisarão desenvolver não apenas conhecimento sobre novas ferramentas e metodologias, mas também a capacidade de equilibrar requisitos de negócio e complexidade técnica

5. Espera-se que, no futuro, as formas de desenvolvimento e operação de software adotem abordagens mais flexíveis e adequadas ao contexto. Em vez de grandes organizações e pequenas startups seguirem o mesmo modelo, a tendência será fortalecer a escolha dos processos e ferramentas mais adequados para cada situação

[kaydash]

Com bastante frequência
gestores
esperam que, só por adotar o conceito de DevOps,
uma grande inovação surja sem esforço
— um equívoco das empresas antiquadas
(sejam grandes ou pequenas)

[GN⁺]

Comentários no Hacker News

• O foco no diagrama do "ciclo devops" está em "build, test, deploy"

  • Houve ênfase em velocidade, sem considerar excelência de engenharia
  • Demitiram as equipes de operações e reestruturaram o QA
  • Todas as equipes passaram a ter uma escala de on-call
  • Foram feitas mudanças caóticas no sistema por ganhos de curto prazo
  • Alguns meses depois, cada mudança passou a causar problemas
  • As ferramentas de devops eram úteis, mas caras e frustrantes
  • Os novos desenvolvedores não conhecem devops, mas conhecem contêineres

• Opinião baseada nos problemas enfrentados por equipes de devops

  • Deve ser possível adicionar novos serviços e gerenciar a infraestrutura com segurança
  • Devops virou o padrão, e não há necessidade de trabalho manual de administrador de sistemas

• As críticas ao Kubernetes estão equivocadas

  • Kubernetes é um excelente exemplo de engenharia de software, tem bom suporte e roda em qualquer lugar
  • É melhor aprender Kubernetes do que usar scripts bash aleatórios

• Devops consiste em remover barreiras para facilitar o deploy de software

  • Deploys diários ajudam a entregar código de maior qualidade
  • É importante ter a opção de fazer deploy apenas quando o código estiver pronto
  • Releases mensais geram pressão e podem levar a escolhas ineficientes

• Devops é uma filosofia, não uma metodologia

  • O objetivo é integrar operações ao SDLC
  • A nuvem tornou isso mais fácil
  • O surgimento de equipes de "DevOps" distorceu a filosofia original

• O discurso da liderança sobre "quebrar silos" é quase só ritual

  • Autoridade sem responsabilidade não funciona
  • Os melhores talentos de devops gostam de substituir a si mesmos por código
  • As ferramentas de devops estão maduras e bem documentadas
  • Um desenvolvedor que não aprende Kubernetes é como um desenvolvedor que não conhece comandos Linux

• Se os usuários podem ser os testadores, então devem ser

  • Só existem questões econômicas
  • Se há muitos clientes, deixe que os usuários testem; se há poucos, é preciso testar diretamente

• Equipes de plataforma só são viáveis em grandes empresas

  • Pequenas e médias empresas precisam lidar com estresse e risco por falta de profissionais de devops
  • A ausência de uma equipe de plataforma causa muitos problemas

• Devops é uma filosofia, não uma metodologia

  • A experiência com equipes em silos prova a necessidade de devops
  • Devops permite que a equipe entenda completamente o projeto e faça o deploy

• Devops tem boas intenções

  • Loops rápidos de feedback são importantes para a velocidade de desenvolvimento
  • É preciso encontrar a melhor solução para a organização e o produto