3.11 Arquitetura na nuvem

Visão geral e motivação

A computação em nuvem é alugar a infraestrutura de outra pessoa sob demanda, por uma rede, pagando pelo que você usa e liberando quando terminar. A arquitetura na nuvem é a disciplina de projetar sistemas que tratam esses recursos alugados como o seu lar nativo e não como uma cópia alugada do seu antigo data center. Essa distinção é o ponto inteiro deste capítulo. Você pode mover uma aplicação legada para um provedor de nuvem e não mudar nada no seu design, e obterá uma conta maior e mais ou menos a mesma fragilidade. Ou pode projetar para a nuvem e obter elasticidade, serviços gerenciados que apagam categorias inteiras de trabalho indiferenciado e a capacidade de sobreviver à falha de um prédio inteiro sem chamar ninguém de madrugada. Isso se apoia diretamente nos fundamentos do capítulo 3.1: a arquitetura na nuvem é arquitetura, com as mesmas trocas e atributos de qualidade, aplicada a um substrato que você não possui.

Para grandes equipes as apostas são maiores porque a nuvem reorganiza quem faz o quê. Quando uma equipe consegue provisionar um banco de dados, uma fila e um balanceador de carga global em minutos, o gargalo deixa de ser a aquisição e passa a ser a governança: custo, segurança e consistência entre dezenas de equipes fazendo isso ao mesmo tempo. A nuvem dá a cada engenheiro um cartão de crédito corporativo e um armazém de ferramentas elétricas, o que é maravilhoso e perigoso na mesma medida. Acertar a arquitetura significa capturar o lado bom (velocidade, elasticidade, resiliência) enquanto se instalam as proteções que mantêm sob controle o gasto, a postura de segurança e a residência dos dados.

Empresas e governos sentem os dois gumes com força. As empresas chegam com décadas de sistemas existentes, então a história delas na nuvem costuma ser uma história de migração, cheia de conectividade híbrida e decisões difíceis entre comprar e construir. Os governos carregam o peso adicional da soberania, dos regimes de autorização e dos dados de cidadãos que legalmente não podem sair de certas fronteiras. As decisões aqui (qual modelo de serviço, quantos provedores, onde ficam os domínios de falha, o que roda como serviço gerenciado e o que roda como código seu) moldam custo e risco por uma década.

Princípios fundamentais

Projete para a nuvem, não fotografe o seu data center. A elasticidade, os serviços gerenciados e a consciência dos domínios de falha são os motivos para estar aqui. Um lift-and-shift joga tudo isso fora.
Tudo é provisionado como código. Se um humano o fez existir clicando, ele é não documentado, não repetível e não auditável.
Projete entre domínios de falha de propósito. Regiões, zonas de disponibilidade e serviços falham. A sua arquitetura decide se isso é um dar de ombros ou uma queda.
O modelo de responsabilidade compartilhada é um contrato, não um slogan. Saiba exatamente qual linha o provedor protege e qual linha você protege.
Compre o indiferenciado, construa o diferenciador. Os serviços gerenciados valem dinheiro de verdade para a tubulação. Mantenha a sua vantagem competitiva em suas próprias mãos.
O aprisionamento é um custo a precificar, não um pecado a evitar. A portabilidade tem um preço e a alavancagem tem um valor. Decida deliberadamente, não por reflexo.
O custo é um atributo de qualidade de primeira classe. Na nuvem, a arquitetura e a fatura são a mesma decisão.

Recomendações

Escolha o modelo de serviço deliberadamente e adote o gerenciado por padrão

Os provedores de nuvem vendem ao longo de um espectro capturado pelos modelos como serviço: a Infraestrutura como Serviço (IaaS) aluga computação, armazenamento e rede brutos. A Plataforma como Serviço (PaaS) aluga um ambiente de execução gerenciado para que você implante código sem cuidar de servidores. O Software como Serviço (SaaS) aluga aplicações prontas. A computação sem servidor (serverless), incluindo funções e serviços gerenciados orientados a eventos, leva isso mais longe: você fornece código ou configuração e o provedor trata de todo o provisionamento, escalando a zero quando ocioso. Cada passo acima no espectro troca controle por alavancagem, da IaaS com o máximo de controle e o máximo de ônus operacional ao serverless com o mínimo dos dois.

O padrão deve ser subir tão alto nesse espectro quanto os seus requisitos permitirem. Um banco de dados gerenciado que trata de correções, cópias, failover e escala é quase sempre um uso melhor dos seus engenheiros do que um operado por vocês. Reserve a IaaS de nível mais baixo para os casos que genuinamente precisam dela: hardware especializado, fronteiras incomuns de conformidade, restrições de licenciamento ou desempenho que a oferta gerenciada não atende. Escreva o motivo como um registro de decisão de arquitetura (capítulo 3.1), porque “operamos nosso próprio broker de mensagens” é uma afirmação que deve ser justificada de novo todo ano.

Projete entre regiões e zonas de disponibilidade como domínios de falha explícitos

Uma região de nuvem é uma área geográfica. Dentro dela, as zonas de disponibilidade são data centers fisicamente separados, com energia, refrigeração e rede independentes, próximos o bastante para replicação de baixa latência mas distantes o bastante para que a falha de um não derrube os outros. São as costuras ao longo das quais a nuvem quebra, então a sua arquitetura precisa tratá-las como de primeira classe. A linha de base para qualquer carga séria é multizona: espalhar computação e dados por pelo menos duas, idealmente três zonas, para que perder uma degrade a capacidade em vez de causar uma queda. É um seguro barato que raramente tem uma boa desculpa para ser pulado.

A multirregionalidade é uma decisão mais pesada, ligada às suas metas de resiliência e recuperação (capítulo 3.5) e ao seu plano de recuperação de desastres (capítulo 9.5). Espalhar entre regiões compra a sobrevivência à falha de uma região inteira e pode pôr os dados mais perto dos usuários, mas introduz custo, latência e problemas de consistência reais, porque a replicação síncrona entre regiões é lenta e a replicação assíncrona significa aceitar perda de dados no failover. Decidam com base em objetivos explícitos de tempo e de ponto de recuperação, não num desejo vago de ser “altamente disponível”. A maioria dos sistemas precisa de um multizona robusto e de um caminho testado de recuperação multirregional. Poucos realmente precisam de ativo-ativo entre regiões, e os que o constroem sem precisar pagam pela complexidade todos os dias.

Trate o modelo de responsabilidade compartilhada como uma fronteira arquitetural

A segurança na nuvem funciona sobre um modelo de responsabilidade compartilhada: o provedor protege a nuvem (instalações físicas, o hipervisor, o interior dos serviços gerenciados) e você protege o que põe na nuvem (seus dados, controles de acesso, configuração de rede e código). A linha exata se move conforme você sobe no espectro de serviços. Com a IaaS você corrige o sistema operacional. Com um banco de dados gerenciado, não, mas ainda é seu quem pode se conectar e se os dados estão criptografados. Os incidentes mais caros vêm de ler mal essa linha, o mais famoso sendo o bucket de armazenamento aberto que vaza milhões de registros porque alguém presumiu que o provedor o tornava privado por padrão.

Deixe a fronteira explícita nos seus designs e entregue os detalhes ao capítulo 4.3, que cobre a segurança de infraestrutura e de nuvem em profundidade. Arquiteturalmente, os imperativos são constantes: criptografar os dados em repouso e em trânsito por padrão, conceder o menor privilégio pela identidade e não pela posição na rede, manter pequeno o raio de impacto de qualquer credencial isolada e presumir que qualquer recurso alcançável pela internet será sondado em minutos. Embuta isso na sua landing zone para que as equipes o herdem.

Provisione tudo como código, dentro de uma landing zone governada

Numa prática madura de nuvem, nenhum recurso de produção existe porque uma pessoa clicou num console. Tudo é declarado como infraestrutura como código (capítulo 8.2), versionado, revisado e aplicado por um pipeline, de modo que a sua infraestrutura é reproduzível, auditável e comparável. É isso que torna real, e não aspiracional, o multizona, o multirregional e a recuperação de desastres: você consegue levantar um ambiente idêntico numa nova região porque o ambiente é um programa, não uma lembrança.

Envolva esse código numa landing zone: uma fundação pré-construída e governada de contas (ou assinaturas ou projetos), rede, identidade, registros e proteções sobre a qual toda equipe constrói. Use contas separadas como fronteiras de raio de impacto e de cobrança, para que o erro de uma equipe não alcance os dados de outra e cada real seja rastreado até um responsável. Imponha as proteções como política como código que impede configurações proibidas (um banco de dados público, um volume sem criptografia, um recurso numa região não permitida) em vez de depender de revisão posterior. Uma equipe central de plataforma costuma ser dona da landing zone, o que liga este capítulo à engenharia de plataforma (capítulo 8.4) e aos contêineres e ambientes de execução nativos da nuvem (capítulo 8.3).

Precifique o aprisionamento com honestidade e seja cético quanto à multinuvem

O aprisionamento ao fornecedor é o custo de trocar de provedor, e é um espectro, não um binário. Usar a fila gerenciada de um provedor cria algum aprisionamento. Usar sua plataforma proprietária de aprendizado de máquina cria muito. O medo reflexivo disso leva as equipes a sacrificar alavancagem real (os serviços gerenciados que fazem a nuvem valer a pena) para preservar uma portabilidade que nunca exercerão. O movimento honesto é precificá-lo: para cada dependência significativa, estime quanto custaria de fato sair e pese isso contra o que o serviço economiza agora. Abstrair um serviço gerenciado para continuar portável muitas vezes custa mais, de forma permanente, do que a migração contra a qual você se segura jamais custaria.

É por isso que a multinuvem genuína (rodar a mesma carga em dois provedores) costuma ser um culto ao cargo e não uma estratégia. Ela obriga a descer ao menor denominador comum, dobra a sua superfície operacional e multiplica a especialização que as suas equipes precisam ter, tudo para se proteger de um risco que raramente se materializa. Há razões legítimas para tocar mais de um provedor: um SaaS de melhor categoria de um segundo fornecedor, um mandato de resiliência de um regulador ou uma exigência deliberada de soberania (capítulo 10.11). A nuvem híbrida, que mantém alguns sistemas no local conectados à nuvem, muitas vezes é inevitável durante a migração corporativa e para dados que legalmente não podem se mover. Escolha essas opções de olhos abertos e com uma justificativa escrita, e não porque um slide dizia “multinuvem”.

Arquitete para o custo e adote o pensamento de arquitetura bem projetada

Na nuvem, uma decisão arquitetural é uma decisão de gasto: superprovisionar “por via das dúvidas” aparece na fatura do mês seguinte. Trate o custo como um atributo de qualidade para o qual você projeta e adote as práticas de FinOps, a disciplina de responsabilidade financeira compartilhada pelo gasto na nuvem (capítulo 9.4), para que engenharia, finanças e produto sejam donos da conta juntos. Marque cada recurso com um responsável, torne o custo visível por equipe e por serviço, redimensione continuamente, use o escalamento automático para pagar pela carga e não pelo pico e explore as alavancas de preço (descontos por uso comprometido, capacidade spot para trabalho interruptível) que a nuvem oferece.

Além do custo, use um framework de arquitetura bem projetada (well-architected) como lista de revisão. Os principais provedores publicam um cada, e todos convergem nos mesmos pilares: confiabilidade, segurança, otimização de custo, eficiência de desempenho, excelência operacional e sustentabilidade. Conduzam uma revisão leve na hora do design e periodicamente depois, pontuando o sistema contra cada pilar e registrando as lacunas como trabalho acompanhado. É uma maneira barata de pegar a troca que vocês não notaram.

Compromissos: prós e contras

Abordagem	Prós	Contras
Lift-and-shift (rehospedagem)	Rápido, baixo esforço inicial, sai do data center depressa	Mantém a fragilidade antiga, perde a elasticidade e os serviços gerenciados, muitas vezes custa mais
Redesenho nativo da nuvem	Elasticidade plena, resiliência, alavancagem dos serviços gerenciados	Maior esforço e habilidades iniciais. Mudança maior a absorver
Nuvem única, integração profunda	Simplicidade, alavancagem máxima, menor superfície operacional	Aprisionamento e risco de provedor concentrados
Multinuvem (mesma carga, dois provedores)	Proteção contra falha de provedor, poder de negociação	Design de menor denominador comum, operação e especialização dobradas
Híbrido (nuvem mais local)	Atende às restrições de residência de dados e de legado, migração em etapas	Complexidade de rede, dois modelos operacionais para rodar ao mesmo tempo
Serverless / altamente gerenciado	Trabalho repetitivo mínimo, escala a zero, entrega rápida	Menos controle, específico do provedor, limites de partida a frio e de cota

A tensão central é controle versus alavancagem, e ela atravessa todas as linhas. Quanto mais você entrega ao provedor, mais depressa se move e menos opera, ao custo de um acoplamento mais profundo. A resolução não é escolher um polo, mas situar cada carga deliberadamente: subir alto no espectro gerenciado para a tubulação commodity, ficar mais embaixo onde o controle de fato compensa e precificar o aprisionamento nas duas direções em vez de tratar a portabilidade como gratuita e a dependência como pecado. As grandes organizações se metem em problemas quando deixam o medo (do aprisionamento, da nuvem, do custo) fazer essa escolha por reflexo e não por análise.

Perguntas para discutir com sua equipe

Quais das nossas cargas foram levantadas-e-levadas (lift-and-shift), e estamos pagando preços de nuvem por uma arquitetura de data center? É comum migrar sob um prazo, rehospedar tudo como está e declarar vitória, para depois descobrir que a conta é maior que a do data center e nenhum dos benefícios de resiliência ou de elasticidade se materializou. A auditoria honesta é listar as principais cargas e marcar cada uma como rehospedada, replataformada ou genuinamente redesenhada e depois ver quais ainda rodam em pegadas de tamanho fixo, sempre ligadas e de zona única. Algum lift-and-shift é um primeiro passo legítimo, então a pergunta não é se vocês o fizeram, mas se têm um plano e um cronograma para ir além. Levem o custo por carga e o histórico de incidentes, porque as cargas ao mesmo tempo caras e frágeis são onde o redesenho se paga mais depressa. Se tudo ainda tem o formato do antigo data center um ano depois da migração, vocês compraram um data center mais caro.
Quando uma zona de disponibilidade ou uma região inteira falha, o que de fato acontece, e nós testamos? Muitas equipes acreditam ser resilientes porque implantaram numa nuvem, sem terem projetado seus domínios de falha nem puxado a tomada para conferir. A versão concreta: para cada sistema crítico, quantas zonas ele abrange, quais são o objetivo documentado de tempo e de ponto de recuperação e quando foi a última vez que fizemos um dia de simulação que derrubou uma zona ou ensaiou a recuperação de uma região? O multizona deve ser a linha de base sem graça, então qualquer carga crítica de zona única é um achado. O multirregional é uma decisão mais pesada e cara, ligada a metas explícitas de recuperação, não adotada por padrão. Levem o mapa de dependências, porque a falha que dói costuma ser um serviço compartilhado (um banco de dados, um provedor de identidade) cujo domínio de falha ninguém mapeou. A resiliência que vocês nunca testaram é uma hipótese, não uma propriedade.
Para as nossas maiores dependências de provedor, quanto custaria de fato sair, e esse é um preço que vale pagar para evitar? Os debates sobre aprisionamento tendem a correr por ideologia e não por números, com um campo abstraindo todo serviço gerenciado para continuar portável e outro ignorando por completo o risco de concentração. Deem base a isso: escolham as três dependências mais profundas, estimem o custo real de engenharia e o tempo decorrido para substituir cada uma e pesem isso contra o que o serviço economiza hoje e contra a probabilidade de algum dia trocarem. Acrescentem os riscos que a portabilidade não resolve, como um regulador exigindo uma segunda fonte ou uma regra de soberania sobre onde os dados podem viver, já que esses podem justificar a multinuvem ou a nuvem híbrida mesmo quando a economia pura não justificaria. O objetivo é uma posição deliberada e escrita por dependência, não uma política geral. Uma vez precificado, a maior parte do aprisionamento temido se mostra mais barata de aceitar do que a camada de abstração construída para evitá-lo.
Que serviços estamos operando nós mesmos que o provedor operaria com prazer por nós, e quanto essa escolha custa em horas de engenheiro? Toda a alavancagem da nuvem é entregar correções, cópias, failover e escala a alguém cujo trabalho em tempo integral são essas coisas, e ainda assim as equipes rotineiramente mantêm um banco de dados, um broker de mensagens ou um cluster de busca operados por elas por hábito ou orgulho mal colocado. Para uma grande organização o custo não é o trabalho repetitivo de uma equipe, mas as mesmas operações indiferenciadas reinventadas em uma dúzia de cantos, cada uma um rodízio de sobreaviso e uma fonte de deriva. A consideração concorrente é genuína: hardware especializado, termos de licenciamento, uma fronteira incomum de conformidade ou desempenho que uma oferta gerenciada não atende podem justificar ficar mais abaixo no espectro, então a resposta é por serviço e não geral. Levem um inventário de serviços autoperados, as horas de engenheiro que cada um consome em manutenção e incidentes e o preço da alternativa gerenciada e exijam um registro de decisão de arquitetura para cada “operamos o nosso” justificado de novo todo ano. Em contextos corporativos e governamentais, acrescentem se a escolha de operar por conta própria é de fato uma restrição de conformidade ou de licenciamento ou apenas inércia vestida de uma, porque auditores e donos de orçamento farão a mesma pergunta.
Conseguimos ver quanto cada equipe e serviço nos custa neste mês, e uma pessoa nomeada se sente responsável por esse número? O gasto na nuvem incha em silêncio porque o mesmo autosserviço que deixa um engenheiro provisionar um banco de dados global em minutos também o deixa manter aquilo rodando em tamanho de pico para sempre, e nenhuma linha isolada da fatura parece alarmante. Numa grande organização sem visibilidade de custo por equipe e por serviço, as finanças descobrem o problema meses depois e a reação é um congelamento bruto que pune os disciplinados junto com os desperdiçadores. A tensão é real: perseguir cada dólar desacelera a entrega, então o objetivo é responsabilização e redimensionamento, não austeridade, com o custo tratado como atributo de qualidade para o qual vocês projetam e não um relatório que leem depois do fato. Levem uma divisão de custo por equipe, a parcela do gasto sem marcação ou inatribuível, a utilização atual contra a capacidade provisionada e onde descontos por uso comprometido ou capacidade spot estão sendo deixados na mesa. Para empresas e órgãos governamentais, liguem isso à prática de FinOps e ao escrutínio do gasto público, já que um recurso sem marcação não é só desperdício, mas um achado de auditoria esperando para acontecer.
Uma equipe consegue levantar agora um armazenamento de dados público, um volume sem criptografia ou um recurso numa região proibida, e nós sequer ficaríamos sabendo? A maioria dos incidentes caros na nuvem são erros de configuração e não violações do provedor, e o modelo de responsabilidade compartilhada significa que o bucket de armazenamento que vaza ou o banco de dados aberto à internet está bem do lado de vocês da linha. Impedir isso na escala de muitas equipes é uma questão de landing zone: proteções impostas como política como código que bloqueiam configurações proibidas antes que existam, em vez de uma revisão posterior que as acha depois que os registros já vazaram. A pressão concorrente é a autonomia dos desenvolvedores, porque proteções apertadas demais empurram as equipes para contas-sombra, então o design precisa impedir o genuinamente perigoso e deixar espaço para se mover. Levem um inventário das proteções de fato impostas, uma tentativa honesta de provisionar um recurso não conforme numa conta real e a defasagem de detecção quando a prevenção falha. Em contextos regulados e governamentais, conectem isso à residência de dados e aos regimes de autorização, porque um recurso numa região não permitida não é uma violação de estilo, mas uma infração legal que um auditor tratará como um evento reportável.

Perspectiva por setor

Startup. Vá nativo da nuvem num único provedor desde o primeiro dia e aceite o aprisionamento de propósito. Rode em serverless e serviços gerenciados que escalam a zero e deixe dois engenheiros serem donos de toda a plataforma, porque o seu recurso mais escasso é a atenção, não a portabilidade. Limite o gasto com firmeza, mantenha tudo em infraestrutura como código para que um momento viral não vire uma queda e escreva a decisão deliberada de aprisionamento para revisitar em escala em vez de fingir que é temporária.

Pequena empresa. Sem engenheiro de plataforma e com orçamento apertado, trate a nuvem como algo que você consome e não que você opera. Prefira SaaS e serviços totalmente gerenciados a qualquer coisa que você mesmo execute, apoie-se nos padrões seguros do provedor e deixe o banco de dados gerenciado cuidar de cópias e de failover para que ninguém precise fazê-lo. Enquadre a escolha como comprar versus construir com um dedão firme em comprar, configure um alerta de cobrança para que um recurso esquecido não drene o mês e recorra a uma opção low-code ou gerenciada antes de levantar servidores que você não consegue operar.

Grande empresa. A sua história na nuvem é uma história de migração entre muitas equipes, então a arquitetura é na verdade um problema de governança. Levante uma landing zone governada, com contas por unidade como fronteiras de raio de impacto e de cobrança, proteções de criptografia por padrão e política como código que bloqueia armazenamentos de dados públicos, e deixe uma equipe central de plataforma ser dona dessa fundação. Conduza o FinOps com showback por equipe, condicione os designs significativos a uma revisão bem projetada e gerencie a conectividade híbrida com os sistemas legados de registro que não vão se mover por anos.

Governo. As regras de contratação, a transparência e a soberania moldam toda decisão. Implante numa região de nuvem autorizada ou governamental, documente linha por linha a fronteira da responsabilidade compartilhada para os auditores e fixe armazenamento e processamento em zonas no país com política como código que bloqueia qualquer recurso numa região não permitida. Persigam o regime de autorização exigido, mantenham a evidência de auditoria como um histórico do git e não uma correria e favoreçam serviços gerenciados cuja postura de conformidade o provedor atestará em vez de uma infraestrutura sob medida que vocês mesmos precisam certificar.

Exemplos

Startup. Uma startup de doze pessoas constrói nativo da nuvem desde o primeiro dia num único provedor e não sente culpa por isso. A API roda em funções serverless que escalam a zero durante a noite, os dados vivem num Postgres gerenciado com cópias automatizadas e failover multizona e os trabalhos em segundo plano rodam numa fila gerenciada. Tudo está definido em infraestrutura como código, e dois engenheiros são donos de toda a plataforma porque o provedor opera as partes difíceis. Quando um momento viral leva o tráfego a cinquenta vezes em uma hora, o escalamento automático o absorve e a conta sobe em proporção ao uso real e depois cai de novo. Os fundadores aceitam deliberadamente o aprisionamento como o preço de se mover depressa com uma equipe minúscula, e escreveram essa decisão para revisitar em escala.

Grande empresa. Uma seguradora multinacional com trezentas aplicações legadas conduz uma migração de vários anos governada pelos “6 Rs” (rehospedar, replataformar, recomprar, refatorar, aposentar, reter). As aplicações commodity de baixo valor são rehospedadas depressa para sair de dois data centers dentro de um prazo, a plataforma central de apólices é refatorada para ser nativa da nuvem, as ferramentas caseiras são recompradas como SaaS e os sistemas obsoletos são aposentados. Uma equipe central de plataforma é dona de uma landing zone com contas por unidade de negócio, proteções de criptografia por padrão e política como código que bloqueia armazenamentos de dados públicos, enquanto a conectividade híbrida liga a nuvem aos sistemas legados de registro do mainframe que não vão se mover por anos. O custo é governado por uma prática de FinOps com showback por unidade, e uma revisão bem projetada condiciona o lançamento em produção de cada aplicação.

Governo. Uma agência nacional que presta um serviço de benefícios aos cidadãos é legalmente obrigada a manter os dados dos residentes dentro das fronteiras nacionais e a rodar em infraestrutura autorizada. Ela implanta na região de nuvem governamental do provedor e persegue uma autorização sob um regime como o FedRAMP nos Estados Unidos (com o trabalho de conformidade no capítulo 4.6), documentando linha por linha a fronteira da responsabilidade compartilhada para os auditores. A residência de dados e as preocupações mais amplas de soberania (capítulo 10.11) conduzem uma arquitetura que fixa armazenamento e processamento em zonas no país e bloqueia, por política como código, qualquer recurso numa região não permitida. O sistema abrange três zonas de disponibilidade, com um plano testado de recuperação entre zonas, e provisiona tudo como código, de modo que a evidência de auditoria é um histórico do git e não uma correria.

Justificativa de negócio: motivações, ROI e TCO

A promessa de destaque da nuvem é transformar despesa de capital em despesa operacional: em vez de comprar servidores anos antes da demanda e operá-los com baixa utilização, você paga pelo que usa e escala com o negócio. Isso é real, mas o retorno mais profundo é velocidade e foco. Um serviço gerenciado que apaga correções, cópias e failover devolve essas horas de engenheiro ao trabalho de produto, e provisionar em minutos e não em meses comprime o tempo da ideia à produção. A elasticidade significa que você para de pagar por uma capacidade de pico que usa duas vezes por ano. Quando a arquitetura está certa, isso se compõe num custo total de propriedade que vence o data center em custo e em capacidade.

O custo de errar é igualmente real, então a justificativa de negócio precisa ser honesta. O lift-and-shift sem redesenho muitas vezes eleva os custos sem entregar nenhum dos benefícios, e o gasto sem governança pode inchar em silêncio entre dezenas de equipes até as finanças soarem o alarme. Enquadrem o caso para a liderança em torno de três alavancas: velocidade (entrega mais rápida e provisionamento mais curto), resiliência (incidentes graves menos numerosos e mais curtos) e opcionalidade (entrar num novo mercado ou região sem um projeto de data center). Ponham números na renovação evitada de data center, na redução de pessoal para infraestrutura commodity e nos minutos de queda prevenidos e comparem-nos com o custo da migração e com o investimento contínuo em FinOps e em plataforma. O argumento mais forte raramente é a economia bruta de custo: é o valor de opção de se mover mais depressa que concorrentes que ainda esperam por hardware.

Antipadrões e armadilhas

Lift-and-shift e chamar de “nuvem”. Rehospedar um design de data center em infraestrutura alugada captura os custos e nenhum dos benefícios.
Infraestrutura clicada no console. Os recursos criados à mão são não repetíveis, não documentados e impossíveis de recuperar ou auditar. Trate qualquer mudança manual em produção como um defeito.
Multinuvem como culto ao cargo. Rodar a mesma carga em dois provedores para se proteger de um risco raro, pagando todos os dias em complexidade e em design de menor denominador comum.
“Alta disponibilidade” de zona única. Acreditar que a nuvem é resiliente por padrão enquanto roda cargas críticas numa só zona, sem failover testado.
Ler mal a responsabilidade compartilhada. Presumir que o provedor protege o que na verdade é de vocês, o caminho clássico para um bucket público vazando milhões de registros.
O custo como reflexão tardia. Projetar sem considerar o gasto e depois descobrir que a fatura tomou as suas decisões arquiteturais por vocês.

Modelo de maturidade

Nível 1, Iniciar: O uso da nuvem é ad hoc e reativo. As equipes clicam recursos para a existência em contas compartilhadas, as cargas são lift-and-shift, e não há landing zone, nem visibilidade de custo, e a resiliência é presumida e não projetada. A primeira queda séria ou o choque da conta é uma surpresa.
Nível 2, Desenvolver: Aparecem práticas básicas, mas variam por equipe. Parte da infraestrutura central é provisionada como código e algumas cargas rodam em multizona, algumas contas são separadas, mas a cobertura é desigual: as escolhas de modelo de serviço e de aprisionamento são feitas por hábito, o custo é observado depois do fato, as proteções são inconsistentes e a recuperação multirregional não é testada.
Nível 3, Padronizar: Uma landing zone governada com proteções de política como código é documentada e imposta em toda a organização. Uma equipe de plataforma é dona da fundação, tudo em produção é provisionado como código, as revisões bem projetadas condicionam os designs significativos e as decisões de comprar versus construir e de domínios de falha são deliberadas e registradas de forma consistente em todas as equipes.
Nível 4, Gerenciar: O parque é medido e controlado em relação a linhas de base. O custo por equipe e por serviço é acompanhado por meio de FinOps contra metas, os objetivos de tempo e de ponto de recuperação são verificados e não afirmados, as violações de proteções e o desvio de configuração são expostos como métricas, o redimensionamento é conduzido por dados de utilização e cada decisão de seguir ou não é sustentada por evidências de painéis de custo, confiabilidade e segurança.
Nível 5, Orquestrar: A arquitetura na nuvem é continuamente melhorada e integrada ao planejamento de negócio e de risco. Os domínios de falha são exercitados por dias de simulação de rotina, o redimensionamento e a precificação são automatizados, a soberania e a residência são impostas por política, as posições de modelo de serviço e de aprisionamento são reprecificadas numa cadência regular e o portfólio de cargas é reequilibrado de forma adaptativa conforme o mercado, os preços e o quadro de riscos mudam.

Ideias para discussão

Em que ponto do espectro da IaaS ao serverless fica cada uma das suas principais cargas, e alguma poderia subir mais para se livrar do trabalho repetitivo operacional sem perder controle de que vocês realmente precisam?
Se o seu provedor principal subisse os preços de forma brusca ou sofresse uma queda regional de vários dias, qual é o plano real de vocês, e ele justifica alguma complexidade de multinuvem ou de nuvem híbrida que vocês carregam?
Quem é dono da sua landing zone e das proteções dela, e uma equipe consegue entregar hoje um recurso não conforme (armazenamento de dados público, volume sem criptografia, região não permitida)?
Para uma carga regulada ou soberana, vocês conseguem produzir como evidência a fronteira de responsabilidade compartilhada e a configuração autorizada sem um treinamento de incêndio?

Principais conclusões

Projete para a nuvem em vez de fotografar o seu data center. A elasticidade, os serviços gerenciados e a consciência dos domínios de falha são os motivos para estar aqui.
Suba no espectro de modelos de serviço rumo ao gerenciado e ao serverless para o trabalho commodity e mantenha o controle mais embaixo só onde ele genuinamente compensa o custo.
Faça das regiões e das zonas de disponibilidade domínios de falha explícitos: multizona como linha de base, multirregional ligado a metas testadas de recuperação.
Provisione tudo como código dentro de uma landing zone governada, com proteções de política como código, contas separadas e uma equipe de plataforma que é dona da fundação.
Precifique com honestidade o aprisionamento ao fornecedor nas duas direções e seja cético quanto à multinuvem a menos que um motivo concreto de regulação, soberania ou o melhor da categoria a exija.
Trate o custo como atributo de qualidade de primeira classe por meio de FinOps e conduza revisões bem projetadas para pegar as trocas que vocês perderam.

Referências e leitura complementar

Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing (NIST Special Publication 800-145)
Amazon Web Services, AWS Well-Architected Framework
Microsoft, Azure Well-Architected Framework and Cloud Adoption Framework
Google Cloud, Google Cloud Architecture Framework
Stephen Orban, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT (and the “6 Rs” migration strategies)
J.R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
Gregor Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration
U.S. General Services Administration, FedRAMP programme documentation and security baselines
Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing