Fundamentos da computação em nuvem
Os cargos que os times de nuvem contratam
Os cargos de trabalho em nuvem que as empresas realmente contratam, o que cada um faz no dia a dia, e como diferenciar um engenheiro de nuvem de um arquiteto de nuvem, de um DevOps Engineer, de um SRE e de um especialista em segurança em nuvem.
- Identificar os principais cargos de nuvem que os times contratam e o que cada um faz no dia a dia
- Diferenciar um arquiteto de nuvem de um engenheiro de nuvem pelo escopo, pela senioridade e pela autoridade de decisão
- Explicar como DevOps e Site Reliability Engineering tratam a operação como uma disciplina de engenharia de software
- Relacionar cada cargo de nuvem aos modelos de serviço, segurança e confiabilidade vistos antes neste curso
Quando uma habilidade vira 5 títulos de vaga diferentes
Você termina o domínio de segurança deste curso confortável com políticas de IAM e o modelo de responsabilidade compartilhada. Abre um site de vagas e pesquisa "cloud". Os resultados voltam como "Cloud Engineer", "Cloud Architect", "DevOps Engineer", "Site Reliability Engineer" e "Cloud Security Engineer", e metade delas pede os mesmos requisitos: AWS ou Azure, rede, IAM, algum script. Nada ali ainda diz qual vaga combina com você.
As vagas não divergem no provedor de nuvem ou nos serviços citados. Elas divergem em 2 pontos: o que você realmente faria no dia a dia, e quanto poder você teria sobre o desenho geral do sistema. Aprenda a ler esses 2 sinais e o site de vagas para de parecer 5 versões do mesmo cargo.
Engenheiro de nuvem (Cloud Engineer): constrói e opera o que a arquitetura define
Um engenheiro de nuvem pega um desenho que já existe, completo ou em rascunho, e constrói: provisiona computação e armazenamento, monta a rede, escreve os scripts de infraestrutura como código vistos antes neste curso, e mantém o sistema rodando saudável depois disso. Esse costuma ser o ponto de entrada mais comum no trabalho com nuvem, porque o dia a dia é concreto e conectado direto aos serviços que você já estudou.
Uma semana típica é subir uma VPC nova a partir de um chamado, descobrir por que um Auto Scaling Group não está lançando instâncias novas, ou atualizar um script Terraform para adicionar uma réplica de leitura no banco de dados. O trabalho é prático e as decisões são majoritariamente locais: como implementar uma parte do sistema, não se o sistema deveria ter esse desenho.
Arquiteto de nuvem (Cloud Architect): projeta o sistema e assume os tradeoffs
Um arquiteto de nuvem trabalha um nível acima. Em vez de implementar uma parte do sistema, decide como o sistema inteiro deveria ser: quais serviços atendem um conjunto de requisitos de negócio, onde ficam os tradeoffs de redundância e custo, e como as peças se conectam. Esse cargo costuma vir depois de vários anos de experiência como engenheiro, porque o trabalho exige antecipar consequências que um profissional menos experiente ainda não teve chance de ver na prática.
Pense num restaurante. O chef executivo decide o cardápio, escolhe os fornecedores e define como a cozinha inteira vai se organizar sob pressão num sábado à noite lotado; essas são as decisões de redundância e tradeoff de um arquiteto de nuvem. O cozinheiro de linha executa exatamente o prato que o cardápio pede, prato após prato, e é aí que mora o trabalho do engenheiro de nuvem. A analogia funciona para a divisão entre projetar e construir, mas quebra num ponto: uma arquitetura de nuvem continua mudando depois de lançada, diferente de um cardápio que fica fixo por meses, então o mesmo profissional acaba alternando entre construir e projetar conforme o sistema evolui. Os 2 papéis se misturam mais na prática do que numa cozinha de verdade.
Fronteira: separando arquiteto e engenheiro numa vaga real
| Dimensão | Engenheiro de nuvem | Arquiteto de nuvem |
|---|---|---|
| Entrega principal | Um sistema rodando e configurado corretamente | Um desenho que atende requisitos de negócio e técnicos |
| Senioridade típica | Júnior a pleno | Sênior, geralmente 5+ anos de experiência em engenharia |
| Escopo de decisão | Como implementar uma parte do sistema | Quais serviços e qual estrutura o sistema inteiro deve usar |
| Tarefa exemplo | Corrigir um health check quebrado num Auto Scaling Group | Escolher entre um monólito em EC2 e um desenho serverless para um produto novo |
DevOps Engineer e Platform Engineer: tratando operação como problema de engenharia
Você já viu o DevOps como prática antes neste curso: a cultura e as ferramentas que fecham o vão entre escrever código e rodar código. DevOps Engineer é essa mesma ideia como título de vaga: alguém que constrói e mantém o pipeline de CI/CD e a automação de infraestrutura como código que deixa os desenvolvedores lançarem código sem repasse manual para um time de operação separado. Platform Engineer é um título próximo, cada vez mais comum, para a mesma ideia de fundo: construir as ferramentas internas e os caminhos prontos que deixam outros engenheiros fazerem deploy sozinhos, com segurança.
Uma tarefa concreta é escrever um pipeline no GitHub Actions que roda os testes, monta uma imagem de container e faz o deploy num ambiente de staging automaticamente a cada merge, sem ninguém copiando arquivo manualmente para um servidor.
Site Reliability Engineer: a mesma ideia, mirando a disponibilidade
O Google, que cunhou o termo, descreve a Site Reliability Engineering direto: SRE é o que acontece quando você pede para um engenheiro de software desenhar uma função de operação. Um SRE passa o dia construindo o monitoramento, os alarmes e a correção automática vistos no domínio de confiabilidade deste curso, os SLIs e SLOs que medem se um sistema está saudável, e a automação que corrige uma classe inteira de falha em vez de corrigir cada incidente à mão.
É tentador ouvir "SRE" e presumir que é administração de sistemas com um nome mais moderno. Não é. A administração de sistemas tradicional responde a problemas um de cada vez, manualmente. SRE responde escrevendo software que previne ou corrige sozinho a categoria inteira do problema, um conjunto de habilidades genuinamente diferente, construído sobre programação, não só experiência de operação.
Cloud Security Engineer: colocando em prática o lado do cliente na responsabilidade compartilhada
Um engenheiro de segurança em nuvem pega o modelo de responsabilidade compartilhada visto antes neste curso e transforma em trabalho do dia a dia: escreve e audita políticas de IAM, procura buckets de armazenamento mal configurados e abertos ao público, revisa configurações de criptografia de dados em repouso e em trânsito, e checa se os controles de governança e conformidade estão realmente aplicados, não só documentados. Esse cargo existe em empresas de qualquer tamanho, porque uma política de IAM mal configurada ou um bucket aberto causa o mesmo estrago numa startup de 3 pessoas e numa empresa grande.
Como os cargos se comparam
| Cargo | Foco principal | Constrói em cima de |
|---|---|---|
| Engenheiro de nuvem | Construir e manter infraestrutura rodando | Computação, armazenamento e rede básicos |
| Arquiteto de nuvem | Projetar sistemas e assumir tradeoffs | Modelos de serviço, custo, padrões de confiabilidade |
| DevOps / Platform Engineer | Automatizar o caminho do código até o sistema rodando | Infraestrutura como código, CI/CD |
| Site Reliability Engineer | Aplicar engenharia de software à disponibilidade | Monitoramento, SLIs e SLOs, resposta a incidentes |
| Cloud Security Engineer | Colocar em prática o lado do cliente na segurança | Responsabilidade compartilhada, IAM, criptografia |
A demanda por trás desses cargos
O Bureau of Labor Statistics dos Estados Unidos não rastreia uma ocupação chamada "Cloud Engineer" diretamente, mas a categoria oficial mais próxima, Computer Network Architects, projeta cerca de 11.200 vagas abertas por ano na próxima década, puxadas em boa parte pela expansão contínua da computação em nuvem e pelos redesenhos de rede que vêm junto. Esse número sozinho subestima a demanda real, porque exclui inteiramente os cargos de desenvolvedor, administrador e segurança focados em nuvem, mas é um sinal conservador e útil de que a tendência é real e rastreada pelo governo, não só marketing do setor.
Entrando sem anos de experiência em produção
É tentador presumir que cada um desses cargos exige anos de experiência prévia on-premises antes de uma empresa considerar você para trabalhar com nuvem. Vagas de nível inicial em nuvem costumam aceitar um tipo diferente de prova: trabalho prático em laboratórios, projetos pessoais que você consegue descrever numa entrevista, e uma certificação básica. Nada disso exige um emprego pago antes, que é exatamente o que a próxima lição deste tópico te prepara para construir.
Onde isso deixa você
Os 5 cargos partem da mesma base de computação, armazenamento, rede e IAM que você construiu ao longo deste curso; o que separa eles é escopo (implementar versus projetar), método (operação manual versus engenharia automatizada) e foco (construir, manter ou proteger). Saber esse mapa diz a você quais vagas realmente combinam com o que você quer fazer no dia a dia. A próxima lição sai de conhecer o mapa para provar que você sabe fazer o trabalho, usando prática gratuita em vez de um emprego pago.
