Computação em nuvem explicada: os 11 conceitos de arquitetura que você precisa saber (Masterclass 4K).

O que este vídeo aborda

• - A Parede da Arquitetura e o Plano Mestre
• - 01. Escalonamento Vertical vs. Horizontal
• - 02. Arquitetura de Balanceamento de Carga (L4 vs. L7 e Verificações de Saúde)
• - 03. Autoscaling e Elasticidade
• - 04. Serverless (FaaS e MicroVMs Firecracker)

Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

- A Parede da Arquitetura e o Plano Mestre

0:00 Todo engenheiro de software eventualmente se depara com a parede da arquitetura em nuvem. Você constrói um aplicativo em seu laptop, o envia para produção, e no momento em que os usuários reais chegam, os servidores travam, as conexões do banco de dados se esgotam, e sua fatura da AWS parece um número de telefone. A maioria dos desenvolvedores tenta resolver a engenharia em nuvem memorizando trezentos acrônimos diferentes de produtos da AWS. Mas a computação em nuvem real não se trata de memorizar catálogos de fornecedores: ela é construída em onze primitivas arquitetônicas fundamentais.

0:34 Nesta masterclass, percorreremos todo o plano empresarial: desde escalonamento e balanceamento de carga até serverless, desacoplamento orientado a eventos, hierarquias de armazenamento e redes em nuvem. Domine esses onze conceitos, e você poderá projetar qualquer backend na AWS, GCP ou Azure. Este é The Daily Diff, por dentro.

- 01. Escalonamento Vertical vs. Horizontal

0:57 Conceito número um: Escalonamento. Quando seu aplicativo experimenta crescimento de tráfego, você tem duas maneiras fundamentalmente diferentes de lidar com a carga: escalonamento vertical, ou escalonamento horizontal. Escalonamento vertical, ou escalonamento para cima, significa pegar sua máquina existente e adicionar mais recursos: atualizando de quatro núcleos de CPU para trinta e dois, ou trocando trinta e dois gigabytes de RAM por cento e vinte e oito. O escalonamento vertical não requer nenhuma alteração arquitetônica: seu código

1:28 e banco de dados permanecem exatamente os mesmos. Mas ele atinge um limite de hardware brutal. Nenhuma máquina no mundo tem dez mil núcleos de CPU, e instâncias de nível superior carregam um prêmio de preço exponencial. O escalonamento horizontal, ou escalonamento para fora, significa manter seus servidores pequenos e com preço de commodity, mas executando várias instâncias em paralelo atrás de um roteador. Se uma instância falhar, os nós restantes absorvem o tráfego com tempo de inatividade zero. A regra de ouro do escalonamento horizontal é a

2:01 ausência de estado: seus servidores de aplicativos não podem armazenar sessões de usuário, arquivos enviados ou estado em seus discos locais. O estado deve residir em um banco de dados externo ou cache, permitindo que qualquer nó lide com qualquer solicitação do usuário.

- 02. Arquitetura de Balanceamento de Carga (L4 vs. L7 e Verificações de Saúde)

2:17 Conceito número dois: Balanceamento de Carga. O escalonamento horizontal parece ótimo no papel, mas introduz um problema imediato: quando dez mil usuários acessam seu nome de domínio, qual servidor específico recebe o tráfego deles? Um balanceador de carga atua como um proxy reverso situado entre a internet pública e seu cluster de backend privado. Ele aceita conexões TCP ou HTTP de entrada e distribui as solicitações entre suas instâncias saudáveis.

2:47 Os balanceadores de carga operam em duas camadas de rede primárias. Os Balanceadores de Carga de Rede da Camada 4 operam na camada de transporte, roteando pacotes TCP e UDP brutos com base no endereço IP e porta com latência de microssegundos e milhões de solicitações por segundo. Os Balanceadores de Carga de Aplicativo da Camada 7 inspecionam o próprio protocolo HTTP: lendo caminhos de URL, cabeçalhos de solicitação, cookies e métodos HTTP. Isso permite o roteamento baseado em caminho: enviando solicitações de slash-api para o seu cluster de backend e solicitações de slash-static para um

3:25 armazenamento de objetos. Crucialmente, os balanceadores de carga realizam verificações de saúde ativas. A cada poucos segundos, o balanceador envia um ping para um endpoint de saúde em cada instância. Se uma instância lançar três erros quinhentos consecutivos ou falhar em responder, ela é automaticamente removida do pool com zero solicitações perdidas.

- 03. Autoscaling e Elasticidade

3:45 Conceito número três: Autoscaling. Se seu aplicativo web precisa de dois servidores às três da manhã, mas vinte servidores durante um lançamento ao meio-dia, clicar manualmente em botões no console da nuvem é um caminho garantido para tempo de inatividade e falência. O autoscaling traz elasticidade dinâmica para pools de servidores horizontais. Um Grupo de Auto Escalamento monitora métricas de desempenho como a utilização média da CPU, I-O de rede ou profundidade do backlog da fila. Quando a CPU média ultrapassa um limite definido — digamos,

4:19 setenta por cento por três minutos consecutivos — o autoscaler automaticamente lança novas máquinas virtuais, as registra com seu balanceador de carga, e começa a rotear o tráfego. Igualmente importante é o escalonamento para dentro: quando a onda de tráfego recua, o autoscaler encerra instâncias em excesso para que você pare de pagar por computação ociosa. Para evitar flapping — onde os servidores são rapidamente criados e destruídos em um loop incessante — arquitetos de nuvem configuram períodos de resfriamento. Conceito número quatro: Serverless.

- 04. Serverless (FaaS e MicroVMs Firecracker)

4:53 Por anos, equipes de marketing apresentaram serverless como código mágico rodando no céu. Na realidade, serverless ainda usa servidores — mas você não os possui, remenda ou paga por eles quando nenhum código está em execução. Com Function-as-a-Service como AWS Lambda ou Google Cloud Functions, você escreve uma função handler autônoma. Quando ocorre uma solicitação HTTP, upload de arquivo S3 ou alteração de banco de dados, o runtime da nuvem inicializa uma micro-máquina virtual

5:23 efêmera como Firecracker em menos de cinco milissegundos. Seu código é executado, retorna uma resposta e é encerrado. Se ninguém visitar seu site por três meses, sua fatura de computação é exatamente zero dólares e zero centavos. Se um milhão de usuários o acessarem simultaneamente, o provedor inicia um milhão de microVMs concorrentes. As compensações de engenharia são reais: latência de cold start ao iniciar runtimes novos, um limite de execução rígido de quinze minutos no Lambda e estrita ausência de estado.

5:55 Serverless é imbatível para pipelines de eventos e APIs esporádicas, mas ruim para WebSockets persistentes ou execuções de treinamento de várias horas.

- 05. Arquitetura Orientada a Eventos (EDA e Desacoplamento)

6:05 Conceito número cinco: Arquitetura Orientada a Eventos, ou EDA. Em arquiteturas tradicionais, os serviços se comunicam sincronicamente. Seu serviço de checkout chama pagamento, pagamento chama estoque, estoque chama fraude, e fraude chama e-mail. Isso cria a cascata síncrona do fim. Se o provedor de e-mail de terceiros experimentar um soluço de rede e levar dez segundos para responder, toda a solicitação de checkout do seu cliente expira com um erro. Em uma arquitetura orientada a eventos, os serviços são completamente desacoplados.

6:37 Quando um cliente clica em comprar, o serviço de checkout não chama serviços downstream. Ele simplesmente publica um evento chamado OrderPlaced para um Barramento de Eventos central como Amazon EventBridge ou um tópico SNS. O checkout é concluído em cinquenta milissegundos. Trabalhadores downstream para pagamento, dedução de estoque e recibos por e-mail extraem mensagens independentemente de suas próprias filas SQS dedicadas. Se o serviço de e-mail ficar inativo por uma hora, as mensagens aguardam em segurança armazenadas em buffer na fila sem um único pedido perdido.

- 06. Orquestração de Contêineres (Docker e Kubernetes)

7:13 Conceito número seis: Orquestração de Contêineres. Docker resolveu o empacotamento: ele envolve seu código de aplicativo, bibliotecas de sistema, configuração e runtime em uma imagem imutável que é executada identicamente em seu MacBook e na nuvem. Mas empacotar um contêiner é fácil. Executar quinhentos contêineres em cinquenta máquinas virtuais físicas é onde a engenharia falha. É por isso que existem orquestradores de contêineres como Kubernetes e AWS ECS.

7:41 Um orquestrador fornece um plano de controle: um servidor de API, um armazenamento de estado etcd e um agendador inteligente. Você declara seu estado desejado: quero dez réplicas do meu serviço de autenticação com dois gigabytes de RAM cada. O agendador inspeciona o cluster, coloca pods em nós com memória livre, configura a rede interna e reconcilia continuamente a realidade. Se um nó sofrer uma falha de hardware, o Kubernetes detecta a perda e reagenda instantaneamente todos os pods deslocados para

- 07. Os 4 Pilares do Armazenamento em Nuvem (S3, EBS, DBs e Redis)

8:16 nós saudáveis. Conceito número sete: A Hierarquia de Armazenamento em Nuvem. Iniciantes geralmente tratam o armazenamento em nuvem como um único bucket onde você despeja arquivos. Na arquitetura de produção, o armazenamento é dividido em quatro pilares distintos com base em padrões de acesso e latência. Primeiro é o Armazenamento de Objetos, como Amazon S3 ou Google Cloud Storage. Você acessa arquivos por meio de APIs REST HTTP usando chamadas simples de PUT e GET. Ele oferece capacidade horizontal infinita a dois centavos por gigabyte por mês,

8:49 tornando-o ideal para vídeo, uploads de usuários, logs e backups. Segundo é o Armazenamento em Bloco, como Amazon EBS. São discos rígidos virtuais montados diretamente em uma máquina virtual específica por meio de interconexões de alta velocidade. Eles formatam em sistemas de arquivos padrão como ext4, suportando acesso rápido de leitura e escrita aleatória exigido por motores de banco de dados. Terceiro são Bancos de Dados Gerenciados: motores relacionais como PostgreSQL no RDS fornecendo transações ACID e junções complexas,

9:21 e motores NoSQL como DynamoDB entregando latência de um único dígito de milissegundos em escala massiva. E quarto são Caches em Memória como Redis. Ler dados da RAM leva microssegundos em vez de milissegundos. Caches ficam na frente do seu banco de dados, protegendo-o do tráfego de leitura repetido e gerenciando tokens de sessão de usuário voláteis.

- 08. Alta Disponibilidade e os Noves (Failover Multi-AZ)

9:44 Conceito número oito: Alta Disponibilidade, ou HA. Disponibilidade responde a uma pergunta: que porcentagem do tempo seu aplicativo está operacional e acessível aos usuários? Em contratos empresariais, a disponibilidade é medida em noves. Dois noves, ou noventa e nove por cento de disponibilidade, permite mais de três dias e meio de tempo de inatividade por ano. Quatro noves reduzem o tempo de inatividade permitido para cinquenta e dois minutos, e cinco noves permitem apenas cinco minutos de tempo de inatividade total por

10:15 ano. Para alcançar alta disponibilidade, você deve eliminar pontos únicos de falha em domínios de falha. Na nuvem, isso significa implantar em várias Zonas de Disponibilidade. Uma Zona de Disponibilidade não é um único rack: são um ou mais data centers físicos distintos, a quilômetros de distância, com energia e refrigeração independentes. Ao executar instâncias ativas na Zona A e na Zona B com replicação de banco de dados síncrona, uma queda de raio ou corte de fibra que derrube uma instalação física inteira resulta em um failover automatizado

10:50 em trinta segundos, com zero intervenção humana.

- 09. Durabilidade vs. Disponibilidade (Por que 11 Noves Não é Uptime)

10:53 Conceito número nove: Durabilidade versus Disponibilidade. Esta é a armadilha conceitual mais comum em entrevistas de arquitetura de nuvem. Engenheiros frequentemente usam as palavras de forma intercambiável, mas elas medem propriedades completamente diferentes. Disponibilidade mede o tempo de atividade: posso fazer uma chamada de API para ler ou escrever meus dados neste exato segundo? Durabilidade mede a preservação: meus dados sobreviverão sem corrupção, danos ou destruição permanente por dez anos?

11:24 Veja o Amazon S3 Standard. Seu Contrato de Nível de Serviço oferece noventa e nove vírgula nove por cento de disponibilidade, o que permite aproximadamente quarenta e três minutos de inatividade por mês onde uma requisição de API pode retornar um erro quinhentos. Mas o S3 promete onze noves de durabilidade: noventa e nove vírgula nove nove nove nove nove nove nove nove nove por cento. Se você armazenar dez milhões de arquivos no S3, pode estatisticamente esperar perder um

11:56 arquivo a cada dez mil anos, em média. O S3 alcança isso codificando objetos por apagamento e replicando partes em pelo menos três instalações de dados geograficamente separadas. Durante uma grande interrupção de rede regional, o S3 pode estar temporariamente indisponível, mas seus dados nunca são destruídos.

- 10. Infraestrutura como Código (Terraform vs. Console Drift)

12:14 Conceito número dez: Infraestrutura como Código, ou IaC. Nos primeiros dias da computação em nuvem, os engenheiros faziam login no console de gerenciamento web da AWS e clicavam manualmente para criar máquinas virtuais, configurar sub-redes e anexar grupos de segurança. A indústria chama isso de ClickOps, e em produção, é um desastre absoluto. Alterações manuais no console não têm trilha de auditoria, nenhum mecanismo de rollback e inevitavelmente causam divergência de configuração entre ambientes de staging e produção. Com ferramentas de Infraestrutura

12:48 como Código como Terraform, OpenTofu, Pulumi ou AWS CDK, você define sua arquitetura de nuvem inteira em arquivos de configuração declarativos armazenados no Git. Cada alteração em uma porta aberta ou réplica de banco de dados passa por uma solicitação pull e revisão por pares. Executar o terraform plan pré-visualiza o diff exato da API antes que algo seja tocado, e subir uma réplica idêntica do seu stack de produção leva quatro minutos em vez de quatro semanas.

- 11. Redes em Nuvem (VPC, Subnets, NAT e Grupos de Segurança)

13:20 Conceito número onze: Redes de Nuvem e Nuvens Privadas Virtuais. Quando você implanta servidores na nuvem, eles não ficam expostos à internet pública. Eles vivem dentro de um limite isolado definido por software chamado VPC. Dentro da sua VPC, você aloca um espaço de endereço IP privado como dez-ponto-zero-ponto-zero-ponto-zero barra dezesseis, e o divide em sub-redes públicas e privadas. Uma sub-rede pública tem uma rota direta para um Internet Gateway.

13:51 Ela contém ativos voltados para o público, como seus Application Load Balancers e NAT Gateways. É a única parte da sua rede que possui endereços IP públicos. Seus servidores de aplicação e bancos de dados de produção vivem estritamente em sub-redes privadas sem IPs públicos e zero rotas de entrada da internet. Quando seus servidores de backend precisam baixar atualizações de segurança, o tráfego de saída deles roteia através do NAT Gateway na sub-rede pública. Ao redor de cada instância estão os Security Groups: firewalls virtuais com estado que impõem o princípio do menor privilégio.

- 12. O Plano Empresarial Completo e o Veredito

14:28 Seu grupo de segurança de banco de dados só aceita conexões na porta 5432 estritamente do grupo de segurança de seus servidores de aplicação, tornando a penetração externa matematicamente impossível. Quando você se afasta, esses onze primitivos se conectam em um sistema coeso. Seu DNS roteia para um Load Balancer em uma sub-rede pública, grupos de autoescalonamento lidam com picos de tráfego em múltiplas Zonas de Disponibilidade, barramentos de eventos desacoplam workers de backend, e todo o seu stack é implantado do Git usando Infraestrutura como Código.

15:02 Veredito da masterclass de hoje: SHIP IT. Pare de memorizar centenas de siglas de marketing de nuvem. Domine esses onze padrões de arquitetura, desacople seu estado, e construa sistemas que não podem falhar. Diga-me qual conceito de nuvem lhe deu a maior dor de cabeça quando você começou a construir, nos comentários. E para pegar o guia completo de arquitetura, assine a newsletter em the daily diff dot dev,

15:28 link abaixo. E esse é o diff de hoje. Eu sou Niko da Axrisi. Faça merges com responsabilidade.

Fontes

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io