O caso
Dois dias de pico, onze meses de ociosidade. O servidor do Dia dos Pais ficou parado o resto do ano.
A cervejaria artesanal de um amigo do Isaac vende quase tudo pelo site. Durante o ano, são poucos pedidos por dia. Na semana do Dia dos Pais, o tráfego vai a dezenas de vezes o normal, e o site cai na primeira noite.
Para não cair, a cervejaria alugou um servidor grande. Ele custa o ano inteiro, e na maior parte do tempo não atende ninguém.
Este post parte de Modelos de Serviço na Nuvem, de Containers na Nuvem e de Compute Engine. Lá, o servidor ainda era seu para gerenciar. Aqui, a pergunta é quem precisa estar ligado quando ninguém está usando.
O problema
Pagar a capacidade do pico o ano inteiro
Com uma máquina virtual, a capacidade é comprada por hora, ligada ou não. Para aguentar o pico, a cervejaria precisa de um servidor que dê conta da Semana do Dia dos Pais. O resto do ano, esse servidor fica pronto para um tráfego que não chega.
- Se o servidor for pequeno, o site cai no pico, justamente quando mais se vende.
- Se o servidor for grande, a conta fica alta na maior parte do tempo.
- Se alguém precisar ajustar a capacidade a cada campanha, o trabalho volta para a equipe.
A solução
Serverless: pagar pelo que roda
Serverless não quer dizer que não há servidor. Quer dizer que você não gerencia os servidores, e que o provedor cria e encerra as instâncias conforme a demanda. Uma comparação possível: é como alugar uma sala de coworking por hora. Você não tem o prédio, não faz manutenção, e paga pelo tempo em que a sala está com você.
Dois comportamentos definem o modelo:
- Escala a zero: sem requisições por um período, o serviço fica sem instâncias.
- Cobrança por uso: o custo acompanha o que foi processado, e não a capacidade ligada.
Três caminhos
Cloud Run, App Engine e Cloud Run functions
Cloud Run
Roda qualquer container que responda a requisições HTTP, em qualquer linguagem.
Na cervejaria: o site inteiro empacotado num container, que sobe quando alguém acessa.
App Engine
Plataforma para aplicações web, com versões e divisão de tráfego entre elas. A versão padrão escala a zero; a flexível não.
Na cervejaria: a versão antiga do site continua ativa enquanto a nova recebe 10% dos acessos.
Cloud Run functions
Uma função que roda quando um evento acontece, como um arquivo novo ou uma mensagem.
Na cervejaria: a função que envia o e-mail de confirmação quando um pedido é pago.
Não confunda
Cloud Run × Cloud Run functions
Cloud Run
“Uma aplicação inteira, ou uma função?”
- Exemplo
- O site da cervejaria, com catálogo, carrinho e painel administrativo, num único container.
- Foco
- Qualquer container que atende requisições HTTP. Você escolhe a linguagem e as bibliotecas.
Cloud Run functions
“Qual evento dispara o código?”
- Exemplo
- Um pedido pago: a função roda, envia o e-mail e termina.
- Foco
- Uma função pequena, disparada por evento. Você escreve só o código da função.
Por baixo
Requisição, instância e cobrança
Quando a primeira requisição chega, o Cloud Run cria uma instância do container. Uma instância pode atender várias requisições ao mesmo tempo, e, quando o tráfego sobe, o serviço cria mais instâncias. Quando o tráfego some, as instâncias ociosas são desligadas depois de um tempo.
Por padrão, o Cloud Run cobra só enquanto processa requisições. Esse modelo tem um custo: quando o serviço estava em zero instâncias, a primeira requisição pode demorar mais, porque a instância precisa ser criada. Esse atraso se chama cold start, e é o preço do escalar a zero.
Na prática
Qual caminho para cada parte da cervejaria
| Parte do sistema | Serviço | Por quê |
|---|---|---|
| Site de vendas, com picos de campanha | Cloud Run | Container HTTP que escala conforme o tráfego |
| Função que envia o e-mail de pedido pago | Cloud Run functions | Roda quando o evento acontece, e termina |
| Painel interno com poucos acessos por dia | App Engine (padrão) | Plataforma simples, que escala a zero |
| Banco de dados dos pedidos | Cloud SQL | Não é serverless: precisa de dados sempre disponíveis |
Termos-chave
Cinco termos para fixar
Toque no cartão para ver a definição.
Teste rápido
Três perguntas, estilo prova
01
Uma API de pedidos recebe muito tráfego uma hora por dia e quase nenhum de madrugada. Qual característica do serverless ajuda mais?
02
Uma equipe quer colocar no ar uma aplicação em container, em qualquer linguagem, que atende requisições HTTP. Qual serviço fica melhor?
03
Qual afirmação sobre serverless é falsa?
A cervejaria não precisava de um servidor para o Dia dos Pais. Precisava de um site que existisse quando alguém acessa e sumisse quando ninguém acessa. Esse é o ponto do serverless, e o próximo passo da trilha é o Kubernetes e o GKE, para quando o container precisa de mais controle sobre a infraestrutura.