Fundamentos de cloud: modelos de serviço, de implantação e responsabilidade compartilhada

A palavra "cloud" é aplicada a tudo, de um serviço de backup para notebook a uma rede global de distribuição de conteúdo, por isso vale começar por uma definição que engenheiros consigam testar. A que quase todo mundo usa como referência vem do National Institute of Standards and Technology (NIST) dos Estados Unidos, na Special Publication 800-145, publicada em 2011 e que continua sendo a referência. Este guia percorre essa definição, depois explica os modelos de serviço, os modelos de implantação e a infraestrutura global que todos os provedores têm em comum, e termina com o modelo de responsabilidade compartilhada — a parte que define o que vai ser culpa sua quando algo quebrar.

As cinco características que fazem algo ser "cloud"

O NIST define cloud computing como um modelo que permite acesso de rede sob demanda a um pool compartilhado de recursos computacionais configuráveis, que podem ser provisionados e liberados rapidamente com esforço mínimo de gerenciamento. Cinco características essenciais destrincham essa frase:

1. Autoatendimento sob demanda. Você mesmo cria uma máquina virtual, uma fila ou um banco de dados, por um console, uma ferramenta de linha de comando ou uma API, sem abrir um chamado para um operador humano.
2. Amplo acesso à rede. Os recursos ficam acessíveis por protocolos de rede padrão, a partir de qualquer tipo de cliente.
3. Pool de recursos. O provedor atende muitos clientes a partir do mesmo pool físico — isso é multi-tenancy — e, em geral, você não sabe nem controla em qual máquina física vai parar, além de uma localização aproximada como uma região.
4. Elasticidade rápida. A capacidade pode crescer e diminuir rapidamente, às vezes de forma automática, e do seu ponto de vista parece ilimitada.
5. Serviço medido. O uso é medido (segundos de CPU, gigabytes-mês, requisições, bytes transferidos) e é esse medidor que gera a fatura.

O teste também funciona ao contrário. Uma plataforma de virtualização operada pelo seu próprio time de operações, por trás de um processo de solicitação de mudança, tem pool de recursos, mas não tem autoatendimento nem elasticidade; o NIST chamaria isso de infraestrutura virtualizada, não de cloud privada. A distinção importa porque a maior parte dos benefícios que as pessoas esperam de "migrar para a cloud" — velocidade, pagamento por uso, escalonamento automático — vem do modelo operacional, e não do fato de o hardware estar em outro lugar.

Elasticidade não é o mesmo que escalabilidade

Escalabilidade é a capacidade de um sistema de suportar mais carga quando você lhe dá mais recursos. Elasticidade é a capacidade de obter e liberar esses recursos automaticamente conforme a carga muda. Um monólito que só roda em uma máquina grande pode ser escalável (você compra uma máquina maior), mas não é elástico. As plataformas de cloud tornam a elasticidade barata de implementar, mas só para sistemas projetados de modo que adicionar uma terceira instância idêntica realmente ajude — tratamento de requisições stateless, armazenamento de sessão compartilhado, filas para absorver picos. Esse trabalho de design é seu; a plataforma só oferece os controles.

Modelos de serviço: o que você deixa de gerenciar

A taxonomia clássica tem três camadas, e outras duas viraram padrão desde que o documento do NIST foi escrito. A forma mais clara de compará-las é perguntar, em cada nível, o que você ainda gerencia.

Daí saem duas regras práticas. Primeiro, quanto mais para a direita você vai, menos trabalho operacional carrega e menos liberdade tem: em PaaS você não consegue instalar um módulo de kernel, e em FaaS seu código tem um tempo máximo de execução e nenhum disco local persistente. Segundo, serviços de dados gerenciados (um PostgreSQL hospedado, um message broker gerenciado) se comportam como PaaS para aquele componente, mesmo quando o resto do sistema está em IaaS. Arquiteturas reais misturam as camadas livremente; o rótulo vale por componente, não por empresa.

Modelos de implantação: quem compartilha o pool

Os quatro modelos de implantação do NIST descrevem para quem a infraestrutura é operada, e na prática o multi-cloud virou um quinto.

Cloud pública. O provedor é dono da infraestrutura e atende o público em geral. Os clientes compartilham o hardware, isolados por virtualização e controles de rede. É isso que "a cloud" quer dizer na maioria das conversas, e é o modelo que o restante desta trilha pressupõe.

Cloud privada. A infraestrutura é operada exclusivamente para uma organização, on-premises ou hospedada por terceiros. Pode ser cloud de verdade (autoatendimento, elástica, medida) quando construída sobre uma plataforma como OpenStack ou VMware com automação de verdade, mas muitas vezes é só virtualização com um portal. Setores regulados a escolhem por questões de residência de dados ou de latência; a contrapartida é que a organização paga antecipadamente pela capacidade de pico e precisa montar e manter o próprio time de plataforma.

Cloud híbrida. Duas ou mais clouds distintas — normalmente um data center privado e um provedor público — ligadas por uma tecnologia que permite mover cargas de trabalho e dados entre elas: um link de rede privado, um provedor de identidade comum, uma camada de orquestração compartilhada. As motivações típicas são migração gradual, manter on-premises um mainframe ou um sistema sensível à latência, ou fazer "bursting" de jobs batch para a cloud pública quando a capacidade local se esgota. É no modelo híbrido que a maioria das grandes empresas realmente vive, e é no encanamento de rede e identidade entre os dois lados que mora a maior parte da dificuldade.

Cloud comunitária. Compartilhada por várias organizações com interesses comuns — um consórcio de hospitais, um conjunto de órgãos públicos. Rara na prática, mas o modelo existe.

Multi-cloud. Usar mais de um provedor público. Às vezes é deliberado (evitar lock-in, atender a um regulador que exige planos de saída, aproveitar o ponto forte de um provedor em analytics e o de outro em identidade), muitas vezes é acidental (um time escolheu AWS, uma empresa adquirida roda no Azure). Portabilidade real entre provedores é cara, porque os serviços gerenciados diferem no comportamento, não só na API; a maioria das estratégias multi-cloud se contenta com uma camada de identidade comum, observabilidade comum e alocação caso a caso, em vez de rodar a mesma carga de trabalho em todo lugar.

Regiões, zonas e edge

Todo grande provedor organiza sua presença nos mesmos três níveis, ainda que os nomes variem.

Uma região é uma área geográfica — uma região metropolitana ou um país — que contém um conjunto de data centers. As regiões são isoladas umas das outras: uma falha de control plane em uma não se propaga para outra, e os dados não saem de uma região a menos que você os mova. Você escolhe uma região por três motivos: proximidade dos usuários (latência), restrições legais sobre onde os dados podem ficar (soberania) e disponibilidade de serviços, já que novos serviços e tipos de instância chegam primeiro às maiores regiões.

Uma zona de disponibilidade (AZ) é um ou mais data centers fisicamente separados dentro de uma região, cada um com sua própria energia, refrigeração e rede, conectados às outras zonas por links privados de alta largura de banda e baixa latência. As regiões da AWS costumam ter três zonas ou mais; o Azure vem adicionando zonas às suas regiões e hoje as oferece na maioria das principais. O contrato de design é que uma falha que afete uma zona deve deixar as outras funcionando. Toda a disciplina de alta disponibilidade se apoia nesse contrato: coloque uma instância em cada uma de duas ou três zonas atrás de um load balancer, e a perda de um data center vira algo que você lê em um relatório, e não uma indisponibilidade.

Edge locations são pequenos pontos de presença, muito mais numerosos que as regiões, que hospedam caches de CDN, resolvedores DNS e, cada vez mais, pequenos runtimes de computação. Elas existem para encurtar a ida e volta até o usuário; não rodam seus bancos de dados.

Region eu-west-1 (Ireland)
├── Availability Zone a  ── data centre(s), own power/cooling/network
├── Availability Zone b  ── data centre(s), own power/cooling/network
└── Availability Zone c  ── data centre(s), own power/cooling/network
        ▲ private low-latency links between zones (synchronous replication feasible)

Region eu-central-1 (Frankfurt)   ── a second region for disaster recovery;
                                     replication is asynchronous over the backbone

Edge locations (hundreds)          ── CDN caches and DNS close to users

Uma consequência pega os iniciantes de surpresa: os nomes das zonas são por conta. A zona que a sua conta chama de a pode ser um prédio físico diferente daquele que outra conta chama de a; os provedores embaralham o mapeamento para distribuir a carga. Use o identificador de zona exposto pelo provedor quando precisar coordenar entre contas.

O modelo de responsabilidade compartilhada

O diagrama mais importante da segurança em cloud tem duas linhas. O provedor é responsável pela segurança da cloud — os prédios, o hardware, o hypervisor, o software dos serviços gerenciados. Você é responsável pela segurança na cloud — tudo o que você configura ou implanta. A fronteira entre as duas linhas se desloca conforme o modelo de serviço.

Três linhas nunca passam para o provedor: identidade, dados e os dispositivos a partir dos quais seus usuários fazem login. É por isso que os grandes vazamentos em cloud pública da última década foram quase todos erros de configuração — um bucket de armazenamento com leitura pública, uma chave de acesso commitada em um repositório público, um banco de dados sem autenticação acessível pela internet — e não falhas da plataforma subjacente. O provedor entrega discos criptografados e políticas de acesso granulares; usá-los ou não é com você.

Dois hábitos práticos decorrem desse modelo. Leia a matriz de responsabilidades de cada serviço gerenciado que você adotar, porque "gerenciado" varia: um control plane de Kubernetes gerenciado não aplica patches nos seus worker nodes a menos que você ative a atualização automática de nós, e um banco de dados gerenciado só aplica patches do engine dentro da janela de manutenção que você definir. E parta do princípio de que as certificações de conformidade do provedor cobrem apenas a metade dele: um certificado ISO 27001 da plataforma não diz nada sobre se a sua aplicação trata dados pessoais de acordo com a lei.

Pagando pelo uso: CapEx, OpEx e a economia real

Infraestrutura on-premises é despesa de capital (CapEx): você compra servidores dimensionados para o pico esperado daqui a três anos, deprecia esses servidores e os mantém rodando com baixa utilização média. Cloud é despesa operacional (OpEx): você paga todo mês pelo que usou. A mudança não é automaticamente mais barata. Ela é mais barata quando a carga é variável, quando você de outra forma superdimensionaria bastante, quando dá para desligar recursos fora do horário comercial ou quando a alternativa era um time montando hardware em racks. É mais cara quando a carga é estável e previsível e a organização já tem o data center e a equipe, e pode ser muito mais cara quando ninguém desliga os recursos que não estão sendo usados.

A medição que torna a cloud flexível também transforma custo em uma questão de engenharia, e não de compras. Cada decisão de arquitetura — quantos dados cruzam as fronteiras entre regiões, se os logs são retidos para sempre, se um job batch roda na capacidade interrompível mais barata — agora aparece em uma fatura em poucos dias. O guia de gestão de custos aprofunda essa disciplina; o ponto fundamental aqui é que, na cloud, engenheiros gastam dinheiro escrevendo código.

Erros comuns

Tratar um lift-and-shift como "estar na cloud". Copiar uma máquina virtual para um provedor e rodá-la exatamente como antes rende uma fatura nova e nenhuma elasticidade. Enquanto a carga de trabalho não conseguir escalar horizontalmente e ser recriada por automação, ela mudou de endereço, não se transformou.

Achar que o provedor aplica patches nas suas VMs. Em IaaS, o sistema operacional é seu. Imagens sem patch e máquinas de teste esquecidas são um achado padrão em auditorias de segurança de cloud. Automatize os patches ou, melhor ainda, recrie as instâncias a partir de imagens novas periodicamente.

Confundir alta disponibilidade com recuperação de desastres. Distribuir instâncias entre zonas resolve a falha de um data center; não adianta nada contra um deploy ruim que corrompe o banco de dados nem contra uma indisponibilidade regional. Backups e, quando se justificar, uma segunda região são decisões separadas — tratadas em alta disponibilidade e recuperação de desastres.

Usar a conta root ou de proprietário no dia a dia. Todo provedor oferece uma identidade de conta única e todo-poderosa. Proteja-a com autenticação multifator por hardware, guarde as credenciais offline e crie identidades com permissões restritas para pessoas e cargas de trabalho.

Ignorar as fronteiras de transferência de dados. O tráfego dentro de uma zona costuma ser gratuito, entre zonas custa um pouco, e entre regiões ou para a internet custa bem mais. Arquiteturas que transferem grandes volumes de dados entre regiões "porque o time de analytics fica lá" surpreendem seus donos no fim do mês.

Principais conclusões

• Cloud computing é definida por um modelo operacional — autoatendimento, elasticidade, pool de recursos, medição, acesso à rede — e não pelo prédio onde os servidores estão.
• Os modelos de serviço formam um espectro de IaaS a SaaS; cada passo para a direita remove tarefas operacionais e controle na mesma medida, e o rótulo vale por componente.
• Pública, privada, híbrida e multi-cloud descrevem quem compartilha o pool; a maioria das grandes organizações está no modelo híbrido, cujas partes difíceis são identidade e rede.
• Regiões isolam falhas e atendem às regras de residência de dados; zonas de disponibilidade dentro de uma região são a unidade da alta disponibilidade; o edge aproxima os caches dos usuários.
• Na responsabilidade compartilhada, o provedor protege a plataforma, enquanto identidade, dados, código da aplicação e configuração continuam sempre sendo seus.
• O pagamento por uso transforma escolhas de arquitetura em escolhas de custo, então ter consciência de custo faz parte da engenharia, e não é um detalhe financeiro para depois.