Bem-vindo à aula 57 do nosso curso de DevOps! Hoje vamos mergulhar em um dos pilares da infraestrutura moderna: a computação em nuvem. Você provavelmente já ouviu falar de AWS, Azure, Google Cloud e outros provedores, mas a verdadeira habilidade de um profissional DevOps está em saber escolher o modelo de computação certo para cada carga de trabalho. Nesta aula, vamos explorar três abordagens fundamentais: máquinas virtuais (VMs), containers gerenciados e serverless. Cada uma tem seus pontos fortes e fracos, e entender isso é essencial para otimizar custos, desempenho e operação.

Imagine que você precisa implantar uma aplicação web. Você poderia alugar uma VM, configurar o sistema operacional, instalar o runtime, e gerenciar tudo manualmente. Ou poderia usar containers gerenciados, onde a plataforma cuida da orquestração e da infraestrutura subjacente. Ou ainda, adotar serverless, onde você só se preocupa com o código, e a nuvem escala automaticamente. Não existe uma resposta única — a escolha depende de fatores como previsibilidade de carga, necessidade de controle, custo e velocidade de desenvolvimento. Vamos analisar cada modelo em detalhe.

VMs

Máquinas Virtuais (VMs) são a forma mais tradicional de computação em nuvem. Elas simulam um computador físico completo, com CPU, memória, disco e sistema operacional próprios. Você tem controle total sobre o ambiente, podendo instalar qualquer software, configurar o kernel, ajustar parâmetros de rede e fazer tuning fino. Isso dá um poder imenso, mas também exige muita responsabilidade: você é responsável por patches de segurança, atualizações do SO, backups e alta disponibilidade (a menos que use serviços gerenciados adicionais).

No contexto DevOps, VMs são frequentemente usadas para workloads legados, aplicações que exigem compatibilidade com sistemas operacionais específicos, ou quando você precisa de um ambiente isolado e previsível. Elas também são úteis para desenvolvimento e testes, pois podem ser facilmente clonadas e descartadas. No entanto, o custo pode ser alto, especialmente se você mantiver VMs ociosas ou não otimizar o tamanho. Além disso, o tempo de inicialização de uma VM é maior (minutos) em comparação com containers (segundos) ou funções serverless (milissegundos).

Exemplo de criação de uma VM na AWS usando a CLI (bash):

# Configurar credenciais da AWS (já deve ter feito antes)
aws configure

# Criar um par de chaves para acesso SSH
aws ec2 create-key-pair --key-name MinhaChave --query 'KeyMaterial' --output text > minha-chave.pem
chmod 400 minha-chave.pem

# Lançar uma instância t2.micro (free tier) com Amazon Linux 2
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t2.micro \
  --key-name MinhaChave \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --associate-public-ip-address

# Conectar via SSH
ssh -i minha-chave.pem ec2-user@IP_PUBLICO

Nesse exemplo, você vê o nível de detalhe necessário: escolher a AMI, o tipo de instância, a chave, o grupo de segurança e a sub-rede. É poderoso, mas trabalhoso. Para simplificar, muitos times usam ferramentas como Terraform ou Ansible para automatizar a criação e configuração de VMs.

Containers gerenciados

Containers são uma abstração mais leve que VMs: eles compartilham o kernel do host, mas isolam o processo e o sistema de arquivos. Isso permite iniciar em segundos e ter uma densidade muito maior por host. Containers gerenciados, como o Amazon ECS, o Google Kubernetes Engine (GKE) ou o Azure Kubernetes Service (AKS), oferecem uma plataforma que cuida da orquestração, escalabilidade, balanceamento de carga e saúde dos containers. Você não precisa se preocupar com a infraestrutura subjacente, mas ainda tem controle sobre a imagem, as variáveis de ambiente, os recursos e a rede.

Para DevOps, containers gerenciados são ideais para aplicações baseadas em microserviços, onde cada serviço pode ser escalado independentemente. Eles também facilitam o ciclo de CI/CD, pois a imagem é imutável e pode ser testada de forma consistente em qualquer ambiente. A curva de aprendizado é maior que serverless, mas menor que VMs, e o custo é geralmente menor que VMs para cargas de trabalho estáveis, porque você pode aproveitar melhor os recursos do host.

Exemplo de deploy de um container no Amazon ECS usando a CLI:

# Registrar uma definição de tarefa (task definition)
aws ecs register-task-definition \
  --family minha-app \
  --network-mode awsvpc \
  --requires-compatibilities FARGATE \
  --cpu 256 \
  --memory 512 \
  --container-definitions '[{"name":"meu-container","image":"nginx:latest","portMappings":[{"containerPort":80}]}]'

# Criar um serviço no cluster (supondo que o cluster já exista)
aws ecs create-service \
  --cluster meu-cluster \
  --service-name meu-servico \
  --task-definition minha-app \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-0123456789abcdef0],securityGroups=[sg-0123456789abcdef0],assignPublicIp=ENABLED}"

Note que usamos Fargate, o modo serverless do ECS, que provisiona automaticamente a infraestrutura para os containers. Isso reduz ainda mais o trabalho operacional. Você também pode usar Kubernetes, que oferece mais flexibilidade e ecossistema, mas exige mais configuração e conhecimento.

Serverless (visão geral)

Serverless é o modelo mais abstrato: você escreve funções ou lógica de negócio, e o provedor de nuvem executa em resposta a eventos, cobrando apenas pelo tempo de execução e recursos consumidos. Não há servidor para gerenciar, nem containers, nem VMs — tudo é abstraído. Serviços como AWS Lambda, Azure Functions e Google Cloud Functions são exemplos clássicos. Você também pode usar backend como serviço (BaaS) para bancos de dados, autenticação, etc.

A principal vantagem do serverless é a escalabilidade elástica: se sua aplicação tem picos de uso, o provedor escala automaticamente, mesmo para milhões de requisições. Além disso, o custo é zero quando ocioso, o que é ótimo para aplicações com tráfego intermitente. No entanto, há limitações: tempo máximo de execução (geralmente 15 minutos em Lambda), restrições de memória e CPU, e cold starts (atraso na primeira chamada após um período de inatividade). Para DevOps, serverless reduz drasticamente a complexidade operacional, mas exige uma mentalidade diferente: você precisa projetar sua aplicação em torno de funções e eventos, e lidar com a observabilidade de forma distribuída.

Exemplo de uma função Lambda em Python (mas o código pode ser em qualquer linguagem suportada):

# Função Lambda simples que responde a um evento HTTP
import json

def lambda_handler(event, context):
    name = event.get('queryStringParameters', {}).get('name', 'Mundo')
    return {
        'statusCode': 200,
        'body': json.dumps({'mensagem': f'Olá, {name}!'})
    }

Para implantar essa função, você pode usar a CLI da AWS:

# Empacotar o código em um zip
zip function.zip lambda_function.py

# Criar a função Lambda
aws lambda create-function \
  --function-name minha-funcao \
  --runtime python3.12 \
  --role arn:aws:iam::123456789012:role/execucao-lambda \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://function.zip

# Invocar a função manualmente
aws lambda invoke \
  --function-name minha-funcao \
  --payload '{"queryStringParameters":{"name":"DevOps"}}' \
  resposta.json
cat resposta.json

Note que você não precisa provisionar nada — a AWS cuida de toda a infraestrutura. Isso é ótimo para automação, processamento de eventos, APIs e tarefas em segundo plano.

Quando usar cada um

A escolha entre VMs, containers gerenciados e serverless não é binária; muitas vezes você combinará os três em uma mesma arquitetura. A regra de ouro é: quanto menos você quiser gerenciar, mais para o serverless você deve ir; quanto mais controle precisar, mais para as VMs. Vamos detalhar os cenários típicos:

VMs: Use quando você precisa de compatibilidade com sistemas operacionais específicos, software legado que não roda em containers, ou quando você quer controle total sobre o ambiente (por exemplo, para requisitos de compliance). VMs também são boas para cargas de trabalho previsíveis e estáveis, onde o custo de ociosidade pode ser mitigado com instâncias reservadas. Se você já tem um data center e quer migrar para a nuvem com o mínimo de mudanças, VMs são o caminho.

Containers gerenciados: Use para aplicações modernas baseadas em microserviços, onde você precisa de escalabilidade rápida, mas também quer algum controle sobre a configuração. Containers são ideais para times que já adotaram Docker e Kubernetes, e para workloads que precisam de portabilidade entre ambientes (on-premises, multi-cloud). Se você tem uma carga de trabalho variável, mas não quer pagar por cold starts, containers gerenciados oferecem um equilíbrio entre custo e desempenho.

Serverless: Use para eventos esporádicos, APIs com tráfego imprevisível, processamento de dados em tempo real, automação de tarefas e integrações. Serverless é perfeito para startups que querem lançar rápido sem se preocupar com infraestrutura, e para funções que ficam ociosas a maior parte do tempo. No entanto, evite serverless para workloads de longa duração, aplicações que exigem baixa latência (cold starts podem ser problemáticos) ou quando você precisa de um ambiente muito específico.

Uma estratégia comum é usar containers gerenciados para a aplicação principal e serverless para funcionalidades auxiliares, como processamento de imagens, notificações ou webhooks. Você também pode usar VMs para bancos de dados legados e containers para serviços web. O importante é avaliar cada componente da sua arquitetura e escolher o modelo que melhor atende aos requisitos de custo, desempenho e operação.

Boas práticas e observações finais

Ao adotar qualquer um desses modelos, siga estas boas práticas:

  • Comece simples: Se você está começando, prefira containers gerenciados ou serverless para não se sobrecarregar com a gestão de VMs.
  • Automatize tudo: Use IaC (Terraform, CloudFormation) para provisionar recursos, e pipelines de CI/CD para implantar alterações.
  • Monitore e observe: Implemente métricas, logs e tracing desde o início. Ferramentas como Prometheus, Grafana, CloudWatch ou Datadog são essenciais.
  • Otimize custos: Revise regularmente o uso de recursos, use instâncias reservadas para VMs, e defina limites de concorrência para funções serverless.
  • Segurança em camadas: Aplique o princípio do menor privilégio nas permissões, use redes privadas e criptografe dados em trânsito e em repouso.
  • Teste em produção: Use estratégias como blue-green deploy ou canary releases para reduzir riscos.

Lembre-se de que a nuvem é um meio, não um fim. O objetivo é entregar valor de forma rápida e confiável, e a escolha do modelo de computação é uma decisão técnica que deve ser revisitada conforme sua aplicação evolui. Não tenha medo de experimentar e mudar de abordagem quando necessário.

Referências

Exercícios

  1. Explique a diferença entre VMs e containers em termos de isolamento e eficiência.

    ✓ Resposta: VMs virtualizam hardware, cada uma com seu próprio sistema operacional convidado, proporcionando isolamento completo, mas com overhead de recursos. Containers compartilham o kernel do host, sendo mais leves e rápidos, mas com isolamento de nível de processo, o que pode ser menos seguro se o kernel tiver vulnerabilidades.
  2. Cite três vantagens e três desvantagens do modelo serverless.

    ✓ Resposta: Vantagens: 1) Escalabilidade automática; 2) Custo zero quando ocioso; 3) Sem gerenciamento de servidores. Desvantagens: 1) Cold starts (latência); 2) Limite de tempo de execução; 3) Dificuldade de depuração e observabilidade.
  3. Em que cenário você escolheria containers gerenciados em vez de VMs? Dê um exemplo concreto.

    ✓ Resposta: Quando você tem uma aplicação baseada em microserviços que precisa escalar rapidamente e deseja reduzir o overhead de gerenciamento de SO. Por exemplo, um e-commerce com picos sazonais, onde cada serviço pode ser escalado independentemente usando Kubernetes ou ECS, enquanto VMs exigiriam provisionamento manual de cada instância.
  4. Qual é o papel do DevOps ao escolher entre esses modelos? Como você tomaria essa decisão em um projeto real?

    ✓ Resposta: O DevOps deve avaliar requisitos de negócio, custo, desempenho, escalabilidade e complexidade operacional. Em um projeto real, eu começaria analisando a previsibilidade da carga, a necessidade de controle de infraestrutura e a maturidade do time. Usaria uma matriz de decisão: se a carga é estável e o time precisa de controle total, VMs; se a carga varia e o time tem experiência com containers, containers gerenciados; se a carga é esporádica e o time quer focar em código, serverless.
  5. Descreva uma arquitetura híbrida que combine VMs, containers e serverless para uma aplicação web completa, explicando o papel de cada parte.

    ✓ Resposta: Uma arquitetura híbrida poderia usar VMs para o banco de dados legado (por exemplo, Oracle), containers gerenciados (ECS) para a API principal em Node.js, e serverless (Lambda) para processamento de imagens e envio de e-mails. As VMs fornecem controle sobre o banco, os containers escalam a API conforme a demanda, e as funções serverless lidam com tarefas assíncronas e eventuais, otimizando custos.