Cloud: compute, storage, bancos e serviços gerenciados sem decorar catálogo

Quando você abre o catálogo de um provedor Cloud pela primeira vez, a sensação pode ser de excesso: dezenas de famílias de máquinas, múltiplos tipos de disco, object storage, file storage, bancos gerenciados, filas, caches, funções, containers e serviços que parecem resolver partes muito específicas da arquitetura.

O erro mais comum é tentar memorizar o catálogo.

Uma forma mais durável de aprender é perguntar:

qual responsabilidade operacional este serviço está assumindo — e qual continua comigo?

Essa pergunta reduz o catálogo a poucos modelos mentais.

No nível mais explícito, você recebe uma máquina virtual e opera grande parte da pilha.

Em storage, você escolhe se precisa de blocos, arquivos compartilhados ou objetos.

Em bancos gerenciados, o provedor passa a assumir tarefas como provisionamento, patching, backups ou alta disponibilidade em graus diferentes.

Em serviços altamente gerenciados, você abre mão de mais controle da infraestrutura em troca de menos operação direta.

O conceito central é simples:

mais infraestrutura explícita
        ↓
mais controle
mais operação sua

mais serviço gerenciado
        ↓
menos infraestrutura para operar
mais contrato com a plataforma

Nenhuma das duas pontas é automaticamente melhor.

O trabalho de arquitetura é escolher o ponto certo para cada problema.

Compute: capacidade para executar trabalho

Compute é a capacidade de executar código usando CPU, memória e outros recursos de processamento.

Uma máquina virtual é a forma mais intuitiva desse conceito porque se parece com um servidor que você já conhece.

Você escolhe uma configuração, recebe um sistema operacional virtualizado e passa a executar processos dentro dele.

AWS usa EC2 como exemplo clássico dessa camada. Google Cloud oferece Compute Engine. Azure oferece Virtual Machines.

Os nomes mudam, mas as responsabilidades são parecidas.

Se você usa uma VM, continua decidindo e operando boa parte de:

• sistema operacional;
• usuários e permissões;
• patching do guest OS;
• runtime;
• processos;
• aplicação;
• firewall do host quando aplicável;
• logs do sistema;
• capacidade da máquina;
• lifecycle do servidor;
• backups daquilo que está dentro dela.

O provedor cuida do data center, hardware físico, virtualização e componentes abaixo da VM.

Isso é uma enorme simplificação comparada a comprar servidor físico.

Ainda assim, você continua operando um servidor.

A VM é uma unidade de controle — e de trabalho

Uma VM é atraente porque oferece liberdade.

Você pode instalar praticamente qualquer runtime suportado pelo sistema, executar agentes, configurar serviços, escolher filesystem e ajustar o host.

Essa liberdade também cria responsabilidade.

Se a máquina fica vulnerável por falta de atualização, o provedor não pode corrigir sua configuração arbitrariamente.

Se o processo da aplicação morre, o hypervisor pode continuar saudável enquanto seu serviço está indisponível.

Se o disco enche, a VM pode existir normalmente enquanto a aplicação falha.

Cloud não torna VM “serverless”.

Ela torna a infraestrutura física invisível.

A operação do guest continua sendo sua.

Containers e serverless sobem o nível de abstração

Containers e funções/serverless aparecem como alternativas porque reduzem partes do trabalho de operar uma VM inteira.

Num serviço gerenciado de containers, você pode entregar uma imagem e deixar que a plataforma cuide de scheduling, substituição de instâncias, integração de rede e parte do scaling.

Em serverless, você pode entregar uma função ou aplicação e deixar a plataforma controlar ainda mais detalhes de execução.

Isso não significa que você “não opera nada”.

Você ainda precisa cuidar de:

• código;
• dependências;
• permissões;
• configuração;
• observabilidade;
• limites;
• concorrência;
• latência;
• custo;
• comportamento diante de falhas.

A diferença é que você deixou de administrar certas camadas do host.

Por isso containers e serverless deveriam ser entendidos como mudanças de responsabilidade, não apenas tecnologias diferentes.

Storage: nem todo dado precisa do mesmo modelo

“Preciso salvar dados” é uma frase ampla demais.

Diferentes workloads precisam de diferentes contratos de armazenamento.

Três modelos aparecem com frequência:

• block storage;
• file storage;
• object storage.

Eles podem parecer semelhantes porque todos guardam bytes.

Operacionalmente, são muito diferentes.

Block storage: um disco para um sistema

Block storage apresenta volumes que uma máquina enxerga de forma parecida com um disco.

É adequado para:

• disco de boot;
• filesystem de uma VM;
• volume de dados;
• workloads que esperam dispositivo de bloco;
• bancos autogerenciados em determinados desenhos.

AWS EBS, Google Persistent Disk/Hyperdisk e Azure Managed Disks são exemplos de famílias de block storage.

O ponto conceitual importante é separar disco físico do host e volume durável de rede.

Em Cloud, um volume pode sobreviver à substituição da VM dependendo do serviço e da configuração.

Isso permite recriar compute sem necessariamente destruir o volume.

Mas persistência não significa backup.

Se um erro de aplicação corrompe os dados no volume, a corrupção pode ser perfeitamente persistente.

Se alguém apaga arquivos, o storage pode obedecer corretamente.

Durabilidade do meio não substitui política de recuperação.

File storage: quando vários consumidores esperam filesystem compartilhado

File storage expõe arquivos e diretórios por protocolos de rede.

É útil quando aplicações realmente precisam de semântica de filesystem compartilhado.

Exemplos incluem:

• aplicações legadas;
• compartilhamentos;
• processamento que depende de diretórios comuns;
• workloads que esperam NFS/SMB;
• conteúdo compartilhado entre máquinas.

AWS EFS, Google Filestore e Azure Files são exemplos de serviços gerenciados desse modelo.

O serviço pode remover a necessidade de construir e operar um file server manualmente.

Ainda assim, continuam decisões sobre:

• permissões;
• capacidade;
• performance;
• protocolo;
• rede;
• backup;
• lifecycle;
• custo.

“É gerenciado” não significa que qualquer workload terá a mesma latência ou throughput de um disco local.

O contrato precisa ser entendido.

Object storage: objetos, não discos remotos

Object storage muda o modelo.

Você não recebe necessariamente um filesystem tradicional.

Você grava objetos identificados por chaves dentro de buckets/containers e acessados por APIs.

Isso combina muito bem com:

• uploads;
• imagens;
• vídeos;
• backups;
• artefatos;
• arquivos de dados;
• conteúdo estático;
• data lakes;
• objetos que não precisam ser tratados como blocos de um disco.

Amazon S3, Google Cloud Storage e Azure Blob Storage são exemplos.

A força desse modelo está em abstrair grande parte da infraestrutura física de storage e oferecer enorme durabilidade e escala.

Mas aplicações precisam ser desenhadas para o contrato.

Um código que pressupõe operações POSIX arbitrárias sobre diretórios locais pode não migrar para object storage apenas trocando um path.

É uma abstração diferente.

Persistência, durabilidade e backup são problemas diferentes

Esses termos são frequentemente misturados.

Persistência responde se o dado sobrevive ao lifecycle do processo ou recurso de compute.

Durabilidade responde quão resistente o sistema de armazenamento é à perda física/interna de dados.

Backup cria uma cópia ou ponto recuperável independente do estado operacional atual.

Um storage altamente durável ainda pode preservar uma exclusão acidental.

Uma base replicada ainda pode replicar um dado corrompido.

Um volume persistente ainda pode estar criptografado por uma chave perdida ou inacessível.

Por isso recovery continua sendo uma responsabilidade arquitetural.

A pergunta não é apenas “onde os dados ficam?”.

É:

de qual tipo de falha preciso conseguir recuperar?

Banco autogerenciado: máximo controle, máxima operação

Você pode instalar PostgreSQL, MySQL ou outro banco numa VM.

Isso oferece controle amplo.

Você decide:

• versão;
• extensões;
• configuração;
• filesystem;
• processo;
• backup;
• replicação;
• failover;
• patching;
• monitoramento;
• upgrade;
• recuperação.

Essa abordagem pode ser necessária quando você precisa de controle profundo ou de uma configuração que o serviço gerenciado não oferece.

Mas a operação é sua.

Se o banco precisa de atualização crítica, sua equipe precisa planejar.

Se o disco falha, a arquitetura precisa recuperar.

Se replica lag cresce, alguém precisa observar.

Se o backup nunca foi testado, o risco continua.

Banco gerenciado: deslocar trabalho operacional

Serviços como Amazon RDS, Cloud SQL e Azure SQL Database existem para tirar parte dessa operação das mãos da equipe.

O provedor pode assumir tarefas como:

• provisionamento;
• patching da infraestrutura e, em muitos casos, do engine;
• backups automatizados;
• integração de monitoramento;
• substituição de hardware;
• recursos de alta disponibilidade;
• failover;
• manutenção de plataforma.

Isso não elimina administração de banco.

A equipe continua responsável por coisas como:

• schema;
• queries;
• índices;
• usuários;
• permissões;
• configuração disponível ao cliente;
• retenção;
• capacidade;
• performance da aplicação;
• testes de restore;
• custos;
• compatibilidade de versão;
• dados.

Um managed database troca trabalho de infraestrutura por um contrato com o serviço.

Essa troca costuma valer muito para equipes pequenas.

Managed service: pagar para não operar uma camada

Esse padrão se repete além de bancos.

Você pode usar um cache gerenciado, fila gerenciada, search gerenciado, serviço de email ou observabilidade como serviço.

A decisão econômica e operacional é:

operar internamente
versus
contratar a capacidade gerenciada

Operar internamente pode dar:

• mais controle;
• customização;
• portabilidade;
• custo direto menor em alguns cenários.

Usar serviço gerenciado pode dar:

• menos patching;
• menos manutenção;
• melhor integração com a plataforma;
• alta disponibilidade pronta;
• scaling simplificado;
• menos conhecimento especializado necessário internamente.

Mas também pode trazer:

• lock-in;
• limites;
• quotas;
• custo variável;
• APIs proprietárias;
• menos liberdade de tuning;
• dependência do roadmap do provedor.

A escolha precisa ser feita pelo problema, não pela quantidade de funcionalidades na página comercial.

Quotas e limites fazem parte da arquitetura

Em infraestrutura própria, um limite costuma aparecer como hardware finito.

Em Cloud, limites também existem como quotas e limites de serviço.

Você pode ter limites de:

• número de VMs;
• CPUs por região;
• volumes;
• requisições;
• conexões;
• tamanho;
• throughput;
• operações por segundo;
• recursos por projeto/conta.

Alguns limites são ajustáveis. Outros pertencem ao contrato do produto.

Arquiteturas que ignoram quotas funcionam até crescerem.

Depois falham de formas que parecem aleatórias.

Por isso capacity planning em Cloud inclui conhecer limites lógicos do serviço, não apenas CPU e memória.

“Escala automaticamente” não elimina capacity planning

Autoscaling ajuda a ajustar compute.

Ele não remove gargalos em dependências.

Se a aplicação escala de 5 para 50 instâncias e todas abrem conexões para o mesmo banco, você pode deslocar o gargalo para o banco.

Se workers escalam com fila crescente, o serviço externo chamado por eles pode começar a aplicar rate limit.

Se serverless cria concorrência rapidamente, storage ou APIs downstream podem não acompanhar.

A capacidade do sistema continua sendo determinada pelo componente limitante.

Cloud facilita adicionar recursos.

Ainda precisamos entender onde eles são úteis.

Escolher serviço pelo problema

Uma forma simples de fugir do catálogo é começar com perguntas.

Para compute

• preciso controlar o sistema operacional?
• o workload é contínuo ou sob demanda?
• precisa de GPU?
• scaling é previsível?
• a aplicação é stateful?
• tenho equipe para operar host?

Para storage

• preciso de bloco, filesystem compartilhado ou objeto?
• qual padrão de leitura/escrita?
• dado é temporário ou durável?
• qual performance?
• precisa ser compartilhado?
• como será recuperado?

Para banco

• preciso de controle profundo do engine?
• managed service suporta minhas extensões?
• qual HA preciso?
• quem fará patching e backup?
• quanto vale reduzir trabalho operacional?

Para serviço gerenciado

• qual trabalho deixa de existir?
• qual novo lock-in aparece?
• quais quotas limitam o sistema?
• qual custo substitui horas da equipe?
• consigo migrar se o contrato deixar de servir?

Essas perguntas continuam válidas em AWS, Google Cloud, Azure ou outra plataforma.

Não compare apenas preço por recurso

Uma VM barata pode exigir horas de administração.

Um banco gerenciado mais caro pode eliminar uma grande parte do trabalho de patching, failover e backup.

Um serviço serverless pode custar mais por unidade e menos no total se fica ocioso grande parte do tempo.

O custo precisa incluir:

• infraestrutura;
• engenharia;
• operação;
• incidentes;
• plantão;
• upgrades;
• recuperação;
• risco.

O serviço “mais barato” no catálogo não é necessariamente o mais barato para o sistema.

A arquitetura Cloud é uma escolha de responsabilidades

Quando você olha para um diagrama Cloud, tente identificar três coisas:

o que executa?
compute

onde o estado vive?
storage / banco

quem opera cada camada?
equipe ou serviço gerenciado

Depois adicione rede e identidade.

Essa leitura é muito mais estável do que decorar nomes comerciais.

Um serviço pode ser renomeado.

Uma nova opção pode surgir.

O princípio continua:

quanto mais responsabilidade entregamos ao provedor, mais precisamos entender o contrato da abstração que recebemos em troca.

O próximo passo natural é responder quem pode acessar cada recurso.

Não basta ter VM, storage e banco corretamente escolhidos.

Precisamos definir identidades, permissões e fronteiras de autorização.

É aí que entra IAM.

Portabilidade não significa evitar todo serviço gerenciado

Existe um reflexo comum quando aparece o tema lock-in:

“então vamos usar apenas VM e software que podemos instalar em qualquer lugar”.

Essa estratégia reduz algumas dependências proprietárias, mas também pode transferir muito trabalho operacional de volta para a equipe.

Portabilidade precisa ser tratada como requisito, não como religião.

Pergunte:

• qual probabilidade real de migrar este componente?
• quanto custaria operar a alternativa mais portátil?
• qual vantagem concreta o serviço gerenciado compra hoje?
• dados podem ser exportados em formato utilizável?
• aplicação depende de uma API proprietária ou apenas de um protocolo comum?
• existe plano de saída proporcional ao risco?

Um PostgreSQL gerenciado pode criar dependência do serviço em backup, observabilidade e failover, enquanto ainda mantém um engine conhecido e ferramentas familiares.

Já um banco ou serviço completamente proprietário pode oferecer recursos excelentes em troca de uma migração futura mais difícil.

Essa troca pode ser racional.

O objetivo não é maximizar portabilidade a qualquer custo.

É conhecer o contrato de saída antes de construir uma parte crítica do sistema em cima dele.

A mesma lógica vale para compute e storage: abstrações mais simples costumam ser mais portáveis; abstrações mais altas podem reduzir trabalho e acelerar produto.

Arquitetura Cloud madura sabe qual dependência está aceitando e por quê.

Saia na Frente

Receba o filtro da semana

IA, produto e negócio — sem avalanche.

Website

Nome (opcional) E-mail

Aceito a Política de Privacidade. Receber o filtro