Existe um momento na carreira de todo desenvolvedor em que o código funciona perfeitamente na máquina local — e quebra em produção. Ou funciona em produção, mas ninguém sabe como foi parar lá, quem fez o deploy, ou o que vai acontecer na próxima atualização. DevOps nasceu para resolver exatamente esse problema.
Não é uma ferramenta, não é um cargo e não é uma metodologia com manual de 300 páginas. DevOps é uma forma de pensar o desenvolvimento de software de ponta a ponta: do commit do desenvolvedor até o serviço rodando em produção, monitorado, seguro e capaz de se recuperar de falhas sem intervenção manual.
E Cloud é o ambiente onde tudo isso acontece. AWS, Azure e Google Cloud não são apenas servidores alugados — são plataformas completas de infraestrutura que permitem escalar de zero a milhões de usuários sem comprar um único cabo de rede.
O que mudou no mercado
Até alguns anos atrás, o desenvolvedor escrevia código e "jogava por cima do muro" para uma equipe de operações que cuidava dos servidores. Esse modelo não sobreviveu ao ritmo do software moderno. Times que fazem dezenas de deploys por dia não podem depender de processos manuais e silos entre equipes.
O profissional que entende tanto de desenvolvimento quanto de infraestrutura — que consegue escrever um pipeline de CI/CD, containerizar uma aplicação, provisioná-la na nuvem e monitorá-la em produção — tornou-se um dos perfis mais requisitados e mais bem remunerados do mercado de tecnologia.
Ferramentas como Docker, Kubernetes, Terraform e GitHub Actions deixaram de ser diferenciais e viraram requisitos. Saber usá-las com propriedade, e não apenas superficialmente, é o que separa um profissional júnior de um sênior no mercado atual.
A proposta desta série
Este curso foi desenhado para levar um desenvolvedor iniciante a um profissional completo de DevOps e Cloud, com uma progressão deliberada: cada módulo constrói sobre o anterior. Não há atalhos, mas há um caminho claro.
Os artigos são publicados semanalmente com conteúdo direto — conceito, contexto, código e prática. Sem enrolação, sem teoria descolada da realidade. Você não vai encontrar Kubernetes no segundo mês, assim como não aprenderia cálculo antes de álgebra.
Ao final do currículo principal, há ainda uma trilha de extensão cobrindo o que o mercado de 2025 já considera diferencial competitivo: Microsoft Azure, plataformas Git alternativas e IA aplicada a operações. Essa trilha não é obrigatória, mas é o que completa o repertório de quem quer atuar nos projetos mais exigentes.
O que você vai aprender
Currículo Principal
| Módulo | Tema |
|---|---|
| 1 | Fundamentos do Terminal e Linux |
| 2 | Controle de Versão com Git e GitHub |
| 3 | Containers com Docker |
| 4 | CI/CD na Prática |
| 5 | Infraestrutura como Código |
| 6 | Cloud Computing com AWS |
| 7 | Kubernetes |
| 8 | Observabilidade e Monitoramento |
| 9 | Segurança, Custos e Carreira |
Trilha de Extensão
| Bloco | Tema |
|---|---|
| A | Microsoft Azure |
| B | Plataformas Git Alternativas |
| C | AIOps e IA Aplicada a DevOps |
Ferramentas que você vai dominar
Ao longo do currículo principal: Linux, Bash, Git, GitHub, GitHub Actions, Docker, Docker Compose, Terraform, Ansible, AWS, Kubernetes, Helm, Prometheus, Grafana e Loki.
Na trilha de extensão: Azure, AKS, Azure DevOps, GitLab, GitLab CI, Bitbucket, Gitea e ferramentas de AIOps e observabilidade com IA.
Para quem é esta série?
Para desenvolvedores que querem entender o que acontece com o código depois que ele sai da máquina local. Para quem já trabalha com tecnologia e quer migrar para a área de infraestrutura e cloud. Para estudantes que querem entrar no mercado com um perfil valorizado. E para profissionais de TI que usam essas ferramentas no dia a dia mas nunca tiveram uma progressão estruturada para entendê-las de verdade.
Não é necessário experiência prévia com servidores ou cloud. É necessário curiosidade, disposição para praticar e vontade de entender o que está por trás de cada comando.
Exercícios
Exercício 1
Qual é o problema concreto que deu origem ao DevOps, e por que resolvê-lo exige olhar o ciclo inteiro do software em vez de só a fase de desenvolvimento?
Ver resposta
✓ Resposta: O problema é a ruptura entre o que funciona na máquina do desenvolvedor e o que funciona em produção — código que quebra ao sair do ambiente local, ou que chega à produção sem que ninguém saiba quem fez o deploy nem o que vai acontecer na próxima atualização. Resolver isso na fase de desenvolvimento é impossível, porque a falha aparece justamente na passagem entre etapas: build, deploy, execução e monitoramento. Por isso DevOps trata o caminho completo, do commit até o serviço rodando em produção, monitorado, seguro e capaz de se recuperar de falhas sem intervenção manual.
Exercício 2
O texto cita o modelo de "jogar o código por cima do muro". Explique o que era esse modelo e aponte a razão específica que o tornou inviável.
Ver resposta
✓ Resposta: Nesse modelo o desenvolvedor escrevia o código e o entregava a uma equipe de operações separada, que cuidava dos servidores — nenhum dos dois lados tinha visão do trabalho do outro. A razão específica de sua inviabilidade é a frequência de entrega: times que fazem dezenas de deploys por dia não conseguem sustentar esse ritmo com processos manuais e silos entre equipes. Cada handoff vira fila e ponto de falha, e o custo disso cresce proporcionalmente ao número de deploys.
Exercício 3
Docker, Kubernetes, Terraform e GitHub Actions deixaram de ser diferenciais e viraram requisitos. Se todo mundo precisa saber essas ferramentas, o que passa a diferenciar um profissional júnior de um sênior?
Ver resposta
✓ Resposta: A profundidade do domínio. Quando a ferramenta é requisito, saber que ela existe e rodar os comandos do tutorial não diferencia ninguém — isso é o piso. O diferencial é usá-la com propriedade: entender o que cada comando faz por baixo, saber quando não usar a ferramenta, diagnosticar por que falhou e prever o impacto de uma mudança em custo, segurança e disponibilidade. É exatamente essa diferença entre uso superficial e domínio real que separa júnior de sênior no mercado atual.
Exercício 4
Kubernetes só aparece no módulo 7, e não no início do currículo. Justifique essa ordem a partir dos módulos que vêm antes dele.
Ver resposta
✓ Resposta: Porque Kubernetes orquestra coisas que precisam existir primeiro. Ele agenda e escala containers, então pressupõe Docker (módulo 3); é operado por linha de comando sobre servidores Linux, o que pressupõe os módulos 1 e 2; entrega valor real dentro de um fluxo automatizado, o que pressupõe CI/CD (módulo 4) e Infraestrutura como Código (módulo 5); e roda sobre uma nuvem, o que pressupõe AWS (módulo 6). Começar por ele seria decorar comandos sem entender o que estão orquestrando — a mesma razão pela qual não se aprende cálculo antes de álgebra.
Exercício 5
Qual é a diferença de papel entre o Currículo Principal e a Trilha de Extensão, e em que situação faz sentido investir tempo nos blocos A, B e C?
Ver resposta
✓ Resposta: O Currículo Principal são os nove módulos que formam a base completa, de Fundamentos de Linux até Segurança, Custos e Carreira — é a progressão que transforma um iniciante em profissional de DevOps e Cloud, e cada módulo depende do anterior. A Trilha de Extensão (A: Microsoft Azure, B: plataformas Git alternativas, C: AIOps e IA aplicada a DevOps) não é obrigatória e não constrói a base: cobre o que o mercado já trata como diferencial competitivo. Faz sentido investir nela depois de concluído o principal, ou antes disso quando o contexto exigir — uma empresa que roda em Azure em vez de AWS, um time em GitLab em vez de GitHub — e para quem pretende atuar nos projetos mais exigentes.