no modelo tradicional de desenvolvimento de software, existem dois mundos isolados:
- time de desenvolvimento (dev): focado em criar novas funcionalidades, escrever código e inovar. o objetivo é a mudança.
- time de operações (ops): focado em manter o software funcionando em produção, estabilidade, monitoramento e suporte a falhas. o objetivo é a estabilidade.
nesse modelo, o software pronto acaba sendo “jogado por cima do muro” para o time de operações se virar para manter rodando. não existe cultura de colaboração. quando o sistema cresce, cada mudança vira um risco para a estabilidade; para mitigar o risco, os processos tornam-se burocráticos, o que trava o fluxo de entrega. cada falha leva muito tempo para ser resolvida (MTTR alto) porque ops não sabe o que dev mudou, e dev não tem acesso ao ambiente de ops.
no modelo tradicional, desenvolvimento e operações são mundos separados com objetivos conflitantes: um quer mudar tudo, o outro não quer que nada mude.
devops
devops não é uma ferramenta, nem um cargo. devops é uma cultura. é um movimento profissional que visa eliminar a barreira entre desenvolvimento e operações, garantindo que os times consigam desenvolver, operar e implantar serviços de forma confiável e rápida.
um erro comum é achar que devops é um time separado se existe um time separado fazendo o trabalho de operações, é só um novo nome para o silo. no entanto, embora devops seja uma cultura compartilhada por todos, podem existir especialistas que facilitam a adoção dessa cultura e constroem as ferramentas para que os outros times sejam autônomos. dependendo da empresa, esses cargos podem ser:
- SRE (site reliability engineer): focado em aplicar práticas de engenharia de software para problemas de infraestrutura e operações.
- platform engineer: focado em construir plataformas internas (IDPs) para que os desenvolvedores façam self-service de infraestrutura.
- cloud engineer: especialista na arquitetura e serviços da nuvem utilizada.
ownership
a mudança fundamental é a adoção de uma cultura de ownership. o time responsável pelo serviço cuida de todo o ciclo de vida dele: desenvolvimento, deploy e operação.
“you build it, you run it.”
quando o próprio time que desenvolveu sente os impactos das suas decisões em produção, a qualidade do código e a preocupação com a estabilidade aumentam drasticamente.
monolito vs. microsserviços
uma arquitetura monolítica até pode sobreviver sem uma cultura devops forte, pois é um único sistema, um único ponto de deploy, um único arquivo de log. já em um uma arquitetura distribuída, devops se faz essencial. sem automação e cultura colaborativa, o gerenciamento de dezenas de serviços independentes fica caótico, burocrático e inviável.
o ciclo infinito do devops
devops é baseado em um ciclo de melhoria contínua, integrando todas as fases da criação de software. não há um fim, apenas iterações constantes.
--- title: devops infinite loop --- graph LR A[plan] --> B[code] B --> C[build] C --> D[test] D --> E[release] E --> F[deploy] F --> G[operate] G --> H[monitor] H --> A
para suportar essa cultura, uma série de práticas técnicas são necessárias. sem esses princípios, o gerenciamento (principalmente de microsserviços) falha.
infraestrutura como código (IaC) (build, code, plan)
criar servidores e configurar redes manualmente é inviável em escala. com IaC, toda a infraestrutura é descrita em arquivos de configuração (código). isso permite que a infraestrutura seja versionada, testada e provisionada automaticamente. (Terraform, Ansible, CloudFormation)
continuous delivery (CD) (release, deploy)
automação do deploy, garante que novas versões aprovadas no CI sejam implantadas em ambientes (staging, produção) de forma segura, rápida e repetível.
gerenciamento de configuração e segredos (operate)
cada microsserviço tem suas próprias credenciais (bancos de dados, APIs externas). gerenciar isso em planilhas ou hardcoded no código é um risco de segurança, portanto é necessário um gerenciamento adequado para injetar configurações e segredos de forma segura em tempo de execução, sem expor informações sensíveis. (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets)
auto-scaling (operate, monitor)
o sistema deve ser capaz de alocar mais recursos automaticamente quando a demanda aumenta e liberar recursos quando ela diminui, otimizando custos e performance.
monitoramento e observabilidade (monitor)
entender por que algo está se comportando de determinada maneira a partir dos seus outputs. quando algo quebra, é preciso saber rapidamente: o que quebrou? onde está o problema? precisa escalonar mais recursos? isso exige a centralização dos três pilares da observabilidade: logs, métricas e rastreamento distribuído.
continuous integration (CI) (test, build)
automação de build e testes, garante que o código novo seja integrado e testado frequentemente.