O que é cloud bursting: como funciona e quando faz sentido

Cloud bursting é uma estratégia de infraestrutura em que a aplicação roda o tempo todo em servidores fixos que você já paga e, só durante os picos de demanda, aluga capacidade extra sob demanda em nuvem pública, cobrada por hora. Quando o pico passa, essa capacidade extra é desligada e a cobrança dela termina. O nome vem daí: a carga “estoura” (burst, em inglês) para fora dos seus servidores apenas no momento em que não cabe mais dentro deles.

Todo termo técnico abaixo vem explicado na primeira aparição.

De onde vem a ideia do cloud bursting?

Do formato da demanda: quase nenhuma aplicação usa a mesma quantidade de recurso todo dia. Existe um patamar que se repete durante quase todo o mês e algumas horas em que o uso salta muito acima dele. Daí saem dois tipos de capacidade, com custos diferentes:

• Capacidade base, fixa. O servidor contratado por mês, com quantidade definida de processamento e memória. Custa menos por unidade de recurso e o preço é previsível, mas o teto não muda quando chega mais gente. Uma VPS (servidor virtual alugado com capacidade fixa) é o exemplo mais comum.
• Capacidade elástica, sob demanda. A máquina que você cria por API na nuvem pública, usa por três horas e descarta. Custa mais caro por hora, e por isso só compensa nas horas em que você precisa dela.

Cloud bursting é comprar cada uma pelo que ela faz bem: a fixa para o patamar usado sempre, a elástica só para o excedente. O arranjo tem nome próprio, infraestrutura híbrida: parte da capacidade em servidor próprio ou alugado, parte em nuvem pública, funcionando como um conjunto só. A alternativa é pagar um servidor grande e vê-lo parado onze meses por ano, ou dimensionar só para o dia normal e apostar que o pico não chega.

Cloud bursting: como funciona, passo a passo

É um ciclo de seis etapas que se repete a cada pico.

1. A aplicação já roda distribuída. Ela está empacotada em contêineres (contêiner é uma forma de empacotar a aplicação para que ela seja copiada e executada em outra máquina sem reinstalação) e gerenciada por um orquestrador de contêineres, o software que decide quantas cópias rodam e em quais máquinas.
2. Algo mede a carga continuamente. Processador, memória e volume de requisições são acompanhados, e existe um limite, definido por você, a partir do qual a situação conta como pico.
3. O gatilho dispara o provisionamento. Passado o limite, uma máquina virtual nova é criada na nuvem por chamada de API, sem ninguém clicar em nada.
4. A máquina nova entra na rede e no cluster. Ela sobe uma conexão privada com o servidor fixo e é registrada no cluster de servidores.
5. O tráfego é dividido. As réplicas sobem na máquina nova e ela atende pedidos junto com o servidor fixo. Do lado do visitante nada muda: mesma URL, mesmas páginas.
6. A demanda cai e a capacidade extra sai. Depois de um tempo de espera que confirma o fim do pico, a máquina é esvaziada, as réplicas voltam para o servidor fixo e só então a instância é encerrada. A cobrança para aí.

O que costuma passar batido é o que não se move: banco de dados, arquivos enviados e sessões continuam no servidor fixo. A capacidade extra é descartável, e é isso que torna o arranjo seguro. Se a nuvem falhar no meio do pico, a aplicação segue no ar com a capacidade fixa que já tinha.

Cloud bursting é a mesma coisa que migrar para a nuvem?

Não. Cloud bursting é confundido com quatro coisas diferentes, e o que separa todas elas é onde a aplicação fica e por quanto tempo você paga.

Duas linhas merecem detalhe. Autoescalonamento dentro de um provedor de nuvem é elástico como o cloud bursting, mas a aplicação já está inteira na nuvem e o que varia é o número de máquinas ali dentro. No cloud bursting existem dois lugares, com redes distintas, e é essa junção que dá o trabalho técnico.

CDN não é concorrente do cloud bursting, e muita gente deveria começar por ela. Se o que derruba o site são as imagens dos produtos, a CDN sai mais barata que qualquer capacidade extra. O que ela não faz é atender o que é calculado a cada visita: busca, carrinho, frete, login, checkout. Essa parte roda no seu servidor.

Quando o cloud bursting NÃO faz sentido?

Esta é a seção mais importante do texto, porque cloud bursting é vendido como se servisse para todo mundo, e não serve.

• Quando o pico dura o mês inteiro. Hora de nuvem pública custa mais caro que hora de servidor contratado por mês, então bursting só ganha se a capacidade extra ficar desligada na maior parte do tempo. Demanda que subiu e não desceu não é pico, é o novo patamar, e o certo aí é aumentar a base.
• Quando a aplicação não roda em contêiner. Instalada direto no sistema operacional, não existe nada pronto para copiar no servidor de reforço. Antes de pensar em pico existe o trabalho de empacotá-la em contêiner, que é um projeto por si só.
• Quando a aplicação guarda estado em disco local sem volume compartilhado. Se as sessões de login ficam em arquivo no disco e as fotos enviadas são gravadas na pasta local, a cópia que subiu na nuvem não vê nada disso. O resultado é pior que lentidão: usuário deslogado no meio da compra, imagem que aparece para uns e não para outros.
• Quando o pico é imprevisível e dura segundos. Criar máquina, conectar à rede, subir contêiner e receber tráfego leva minutos, não segundos. Uma rajada de trinta segundos termina antes do reforço chegar. Cloud bursting atende bem pico anunciado (campanha, data sazonal, lançamento) e pico de subida gradual.
• Quando o gargalo é o banco de dados. Capacidade extra multiplica as cópias da aplicação, não o banco. Se o que satura é a escrita, subir mais réplicas pode piorar, porque aumenta a fila de quem quer escrever.

Se o seu caso caiu em qualquer um desses cinco pontos, cloud bursting não é a resposta hoje.

O que precisa existir para o cloud bursting funcionar de verdade?

“Subir máquina no pico” é a metade fácil. Sem estas cinco peças, o arranjo funciona na apresentação e falha no dia:

• Gatilho por métrica. Um limite objetivo, medido continuamente, com tempo de espera antes de agir. Sem isso, ou o reforço nunca entra, ou entra a cada oscilação e o custo dispara.
• Provisionamento automático. Criação da máquina por API, com a receita de inicialização pronta: sistema, rede, chaves, agente. Se depender de alguém logar e configurar à mão, o pico já passou.
• Rede entre o servidor fixo e o efêmero. As duas máquinas estão em provedores diferentes e precisam se falar por um canal privado e cifrado, com endereços estáveis. É a parte mais frágil de qualquer implementação caseira.
• Desligamento que esvazia antes de encerrar. O reforço precisa parar de receber pedidos novos, esperar as réplicas migrarem de volta e só então ser encerrado. Encerrar antes é derrubar requisição de cliente real.
• Teto de gasto. Um limite em dinheiro respeitado pela própria ferramenta, com alerta antes de chegar lá e verificação de máquina esquecida ligada. Hora cobrada sem teto troca site lento por susto na fatura.

Cloud bursting em VPS com AWS: como fica na prática?

O formato mais comum no Brasil hoje é cloud bursting entre VPS e AWS: a aplicação vive numa VPS que já está paga e funcionando, e a capacidade extra nasce como instâncias EC2 (máquinas virtuais da AWS cobradas por hora) na conta AWS da própria empresa.

Duas consequências práticas. A conta das horas extras vem da AWS direto para você, sem intermediário. E a região onde a máquina sobe importa, porque distância vira latência: para público brasileiro, São Paulo (sa-east-1) é a escolha natural.

Onde o SwarmBurst entra

O SwarmBurst implementa essas cinco peças em um agente instalado no servidor onde a aplicação já roda. Esse servidor continua sendo o principal e guardando tudo o que é permanente: banco de dados, arquivos enviados e painel. No pico, o agente cria instâncias EC2 na sua própria conta AWS, liga cada uma ao servidor principal por um túnel cifrado WireGuard e coloca nelas réplicas do serviço da aplicação. Quando o movimento cai, ele esvazia o reforço, espera a migração das réplicas e encerra a instância. Teto de gasto mensal, alertas por e-mail e no painel, região configurável, histórico de eventos e varredura de instâncias que tenham sobrado ligadas já estão entregues. O pré-requisito é o do cloud bursting em geral: a aplicação precisa rodar em contêineres, dentro de um cluster de servidores.

E a parte que interessa a quem desconfia de página de produto: o SwarmBurst já sobe e encerra instância real na AWS em teste validado, mas ainda não passou pelo pico real de uma loja em produção. Não temos cliente, depoimento nem número de resultado para mostrar, e não vamos inventar nenhum. Por isso existe o Piloto do Primeiro Pico: implantação gratuita ou simbólica, um piloto por vez, em troca de autorização para medir e publicar os dados reais do pico e de um depoimento no fim, se a experiência tiver sido boa.

Para loja virtual com pico de data marcada, o checklist prático está em como preparar a loja virtual para a Black Friday sem trocar de servidor.

Perguntas frequentes sobre cloud bursting

O que é cloud bursting em uma frase? Cloud bursting é usar servidor de nuvem pública apenas nas horas de pico, mantendo a aplicação nos servidores fixos que você já paga no resto do tempo. A capacidade extra é cobrada por hora e desligada quando o pico passa.

Cloud bursting é a mesma coisa que autoescalonamento? Não exatamente. Autoescalonamento varia a quantidade de máquinas dentro do mesmo provedor de nuvem, onde a aplicação já está inteira. Cloud bursting acontece entre dois lugares: capacidade fixa própria e capacidade alugada por hora na nuvem, ligadas por uma rede privada.

Cloud bursting reduz custo de infraestrutura? Depende do formato da sua demanda, e não existe percentual honesto para prometer aqui. A economia aparece quando o pico é curto em relação ao mês, porque você deixa de pagar capacidade parada nos dias normais. Se a demanda alta é constante, sai mais caro que aumentar a base.

Preciso migrar minha aplicação para a nuvem para usar cloud bursting? Não, é o contrário: a premissa é que a aplicação continue no servidor onde já está, com banco de dados e arquivos no mesmo lugar. Só a capacidade extra vive na nuvem, e é temporária.

Quanto tempo leva para a capacidade extra entrar no ar? Minutos, não segundos: é preciso criar a máquina virtual, conectá-la à rede privada, registrá-la no cluster e subir as réplicas. Por isso cloud bursting serve para pico previsível ou de subida gradual, não para rajada instantânea.

Cloud bursting funciona com qualquer aplicação? Não. Funciona com aplicação que roda em contêineres num cluster e que não guarde estado no disco local de uma máquina só.

Se a sua aplicação já roda em contêineres e o próximo pico está no calendário, vale conversar antes dele.

Quero o piloto do primeiro pico

É uma conversa no WhatsApp, sem compromisso. A gente diz na hora se o seu caso encaixa.