Em pleno 2024, a era do Platform Engineering, aqui está mais um artigo fresquinho sobre DevOps. Calma, não se desespere! Vamos te apresentar ferramentas de DevOps e SRE que vão impressionar o seu chefe, os colegas de trabalho, ou até mesmo o entrevistador durante uma entrevista técnica!
Dev vs Ops: Quando falamos de DevOps, parece a bala de prata, né? É uma das buzzwords mais legais dos tempos recentes, juntamente com SRE (Site Reliability Engineering), Platform Engineering , Computação em Nuvem (Cloud computing) e tudo e qualquer coisa que tenha a ver com AI, certo? Se existisse um acrônimo tipo DevAIOps, ou ChatDevOps… aí sim, nossos problemas estariam resolvidos!
Não faz sentido para um desenvolvimento de software mais ágil e fluido, por exemplo, ter toda a infraestrutura de computação em nuvem se o processo de planejar, criar e implementar o código não for automatizado, utilizando ferramentas de CI/CD (Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous everything!). Por outro lado, não é correto afirmar que a esteira de desenvolvimento de uma aplicaçação é DevOps só porque utizam o jenkins para fazer CI, mas nem sequer monitoram a aplicação.
Brincadeiras à parte, DevOps é uma metodologia super útil. Mas só funciona se for bem implementada com as ferramentas certas, aquelas que realmente fazem a diferença no ciclo de desenvolvimento de software. Não adianta nada ter toda a infraestrutura na cloud se o processo de CI/CD (Continuous Integration, Continuous Delivery, Continuous Deployment) não estiver afinado. Por outro lado, não dá pra dizer que só usar Jenkins para CI já é ser DevOps.
Dado este cenário, hoje vamos falar de como alcançar o nirvana DevOps do ponto de vista ferramental (tooling). Quais softwares, ferramentas e frameworks são essenciais para afirmarmos, com orgulho, que somos uma equipe DevOps, que cria software com a mentalidade e as ferramentas certas! Dev… Ops! Dev & Ops! Mas antes, vamos relembrar o que é DevOps em sua essência, e não como buzzword.
DevOps Tools: DevOps, em essência, é processo de unir desenvolvimento (Dev) e operação (Ops). É sobre utilizar-se de técnicas, frameworks e ferramentas para garantir qualidade, robustez e confiabilidade do software, a fim de agregar mais valor ao produto e melhorar a experiência do usuário final. Mas, como alcançamos o nirvana DevOps? Hoje, vamos quebrar isso em partes pra entender melhor quais ferramentas e softwares utilizar em cada ciclo DevOps.
Para alcançar a excelência em DevOps e SRE, não basta só montar um time e injetar o mindset correto. Precisamos de ferramentas que nos permitam planejar nosso código de forma ágil, criar o código colaborativamente e de maneira centralizada; arquitetar, compilar e encapsular esse código de forma segura, rápida e eficiente, sem aquela dor de cabeça de ficar refazendo tudo. E mais: testar o software para assegurar sua qualidade, mandar o código para os ambientes de desenvolvimento, stagging até a produção de um jeito fluido, sem depender tanto do trabalho manual; operar esse código e garantir a comunicação entre as equipes. E claro, monitorar o software pra ter total visibilidade e feedback sobre a saúde do sistema.
Parece muita coisa, não é? Quase uma questão de Enem! Mas fica tranquilo, vamos quebrar isso em partes pra ficar mais fácil de entender. Não esqueça de admirar a imagem acima com as DevOps tools, pois vamos destrinchar ela agora:
- Planejamento: Para planejar o software, normalmente as empresas utilizam ferramentas de prateleira para salvar o resultado das muitas reuniões de planning e desenhos da arquitetura do software. Ferramentas como Jira e Confluence são usadas para criação das tarefas da sprint e documentação do software, além de toda a stack da Microsoft ou Google, como por exemplo a criação de documentação de arquitetura no Google Docs ou MS Word, apresentações dos MVPs (minimum viable products) ou ideias no PowerPoint. E claro, muita reunião no Zoom, Google Meet ou Microsoft Teams para planejar esse código que parece sempre ser eterno e nunca sair do papel.
- Código: Codar ou codificar é a parte que os desenvolvedores mais gostam (e mais odeiam quando o product owner/manager ou gerentes ficam pressionando pra sair logo aquela feature que ficou em planejamento por 2 meses mas querem que seja codado em 2 dias). Como diria um grande amigo, só deveria ter o privilégio de cobrar entrega de código quem um dia foi um desenvolvedor e sabe o quanto de trabalho vai dar. Em pleno 2024, quem não utiliza uma ferramenta Git para manter o histórico de seu código em desenvolvimento deveria ser estudado pela NASA por ter tanta coragem! Brincadeiras à parte, utilizar Git é básico e obrigatório para manter um código limpo, sustentável, acessível, padronizado e seguro (do ponto de vista de manter o histórico de mudanças no código). GitHub é a principal ferramenta para tal, mas temos outras opções, como por exemplo Azure DevOps.
- Build: Para “buildar”, ou compilar e executar o código, existe uma variedade imensa de ferramentas que dependem da tecnologia, ou stack, escolhida para criar o código. Java, Golang, Python, Node… cada linguagem de programação tem seus frameworks de build. Para Java, os principais frameworks para automação, injeção de dependências e gerenciamento de dependências são o Spring e o Maven, ou Gradle. Já para o gerenciamento de recursos, principalmente infraestrutura de cloud, a principal ferramenta é o Terraform. O Docker auxilia muito na parte de empacotamento do código em um container após buildar. Já ferramentas que fornecem pipelines para o build, ou CI (Continuous Integration), como GitLab, são mandatórios, afinal de contas, não existe essa de “na minha máquina funciona”. Se o código roda local na sua máquina, ele também deveria rodar na nuvem em uma ferramenta de CI que emula a execução, teste e empacotamento do código local.
- Testes: Assim como o build, os testes variam muito de acordo com a stack e linguagem de programação, ou frameworks de build, escolhidos. Para Java, utiliza-se bastante na indústria o JUnit. Para testar código de forma estática ou realizar testes unitários, o Sonar Cloud (ou Sonar Qube) é quem impera. Existem também testes de segurança que podem ser executados com o Snyk, como os famosos testes de vulnerabilidade de código SAST (Static Application Security Testing), que verificam, entre outros, se existem dependências no código vulneráveis a ataques de hackers, como vulnerabilidade por DDOS (Distributed Denial of Service), por exemplo. Indo além, existem ferramentas de testes de integração, testes de carga (load tests), testes fim-a-fim (E2E tests ou User Experience testing), entre outros tipos de testes, que não faz tanto sentido abordar neste artigo, pois isso é um tópico de um artigo por si só. Exemplos de ferramentas de teste de carga são o JMeter para Java, o Azure Load Testing e o K6.
- Release: Para fazer release, ou seja, enviar o código para os ambientes de development, staging ou prod, não tem muito segredo. Devemos utilizar uma ferramenta de CI/CD que nos permita automatizar o processo de enviar o código compilado, buildado e minimamente testado para algum lugar onde ele possa rodar na nuvem. O Jenkins, GitHub Actions, GitLab e Azure DevOps fazem isso com facilidade e são alguns dos líderes dessa indústria atualmente.
- Deploy: Depois que mandamos o código para ambientes baixos (low environments), como dev ou staging, precisamos realizar o tão temido deploy para produção. É aquele dia que o filho chora e a mãe não vê! É o famoso dia que o dev tem receio e o Ops nem queria estar de plantão. É o dia que todo mundo faz o jutsu de invocação dos SREs e DevOps — de devs à gerentes, de engenheiros cloud até gerentes de produto — todo mundo quer ter um SRE pra chamar de seu no dia do deploy. O super SRE, coitado, no geral, não participou da criação do código, porém, é quem tem o super poder de se virar e buscar ajuda interna, realizar troubleshoot para identificar problemas ou pesquisar possíveis soluções no Google e no StackOverflow. O trabalho dele normalmente é pegar o código e fazer o famigerado deploy noturno em produção. Dito isto, o deploy do código, e da aplicação, normalmente é feito em um ambiente com infraestrutura robusta e elástica, como Kubernetes (utilizando ArgoCD, caso use GitOps), mas também pode ser feito em qualquer um dos serviços de computação dos provedores de cloud, como Amazon Web Services (AWS), Google Cloud Platform (GCP) e Microsoft Azure. No caso de não usar Kubernetes, pode-se optar por fazer o deploy na nuvem em: uma infraestrutura baseada em máquina virtual (VM — Virtual Machine) como AWS EC2, GCP Compute Engine ou Azure Virtual Machines; em uma infra em containers usando Docker; em um serviço serverless, como AWS Lambda, GCP Functions ou Azure Functions; entre outras opções que forneçam capacidade de computação (processamento, armazenamento e acesso à rede).
- Operar: Operar um software é aquilo, né?! Muita comunicação, monitoramento proativo e gerenciamento de incidentes (incident management). Para comunicação, normalmente utilizam-se o Slack, ou qualquer outra ferramenta de troca de mensagens (já fui comunicado de incidentes por ligação, por SMS e até WhatsApp em experiências passadas). Para recebimento de alertas, alarmes e gestão de incidentes, no geral, utilizam-se o OpsGenie ou PagerDuty, mas existem diversas outras plataformas no mercado para gestão de incidentes e colaboração.
- Monitoramento (Observabilidade): Monitorar é crucial, pois sem visibilidade de dados de saúde da aplicação, como métricas, eventos, logs e traces (MELT), estamos às cegas. Pense em monitoramento como o processo de obter dados para entender, analisar a saúde, realizar troubleshooting e ter controle sobre sua aplicação. Não ter monitoramento é como voar um avião com visibilidade zero e sem os instrumentos necessários (radar, sonar, altímetro, velocímetro, sensores de temperatura, etc)… tenho certeza que você não gostaria de estar nesse avião, certo? Pois bem, não queira trabalhar com um sistema ou aplicação que não tenha monitoramento nem observabilidade, pois você estará às cegas. Na indústria, existem ferramentas de prateleira que fazem esse trabalho duro, como por exemplo New Relic, Datadog e Dynatrace. O Open Telemetry, ou OTel, é o agente que coleta os dados e envia para estas ferramentas para que você possa criar os seus lindos dashboards e alertas.
Conclusão
E aí, chegamos ao fim! Com tudo isso, fechamos o símbolo do infinito do DevOps, que se assemelha muito ao processo de retroalimentação CI/CD. A melhoria contínua é a chave do sucesso! Depois de alcançar o deploy em produção e o monitoramento ou observabilidade, usamos os dados coletados e a experiência acumulada no desenvolvimento para levar a aplicação do MVP (minimum viable product) para uma app cada vez maior e melhor. É por isso que o símbolo do DevOps é um infinito, pois representa um loop infinito de desenvolvimento, operação e melhoria contínua; um ciclo que só termina quando o software é desativado (decommissioned), já que todo software tem seu ciclo de vida, também conhecido como SDLC — Software Development Life Cycle. Mas essa é uma história para outro post!
Espero que tenham curtido o artigo! Se gostaram e querem saber mais, não esqueçam de visitar a Toolbox em https://toolboxdevops.cloud/.
