Pular para o conteúdo
use-cases / move-200gb-between-clouds-with-two-curls / hero
PIPE · MIGRAÇÃO ENTRE NUVENS

Mova 200GB entre nuvens com dois curls

Um backup Postgres de 200GB em Frankfurt. Uma máquina nova em Singapura. Você pula o round-trip do S3. Um curl manda pg_dump para uma URL do Hoody pipe; outro curl do outro lado entra direto no psql. Os bytes ficam em voo, nunca em repouso.

use-cases / move-200gb-between-clouds-with-two-curls / mechanism

Não é um bucket. É um roteador.

O Hoody Pipe é um caminho nomeado em um servidor HTTP. O remetente faz PUT de um stream nele, o receptor faz GET do mesmo caminho e o servidor faz splice dos dois. Nada é escrito em disco; o pipe retém zero bytes por design.

Bytes entre dois curlsTTL DE 5 MIN · SEM CAMADA DE STORAGE
01 · REMETENTE

PUT no caminho

Da máquina de origem, pg_dump | gzip | curl -T - para a URL do pipe. O corpo do PUT faz streaming na velocidade que o backpressure de TCP permite. O servidor segura a conexão até um receptor aparecer no mesmo caminho.

PUT /api/v1/pipe/migration
02 · ROTEADOR

Splice em memória

Quando o GET do receptor chega no mesmo caminho, o Hoody faz splice dos bytes do upload direto na resposta do download. Sem buffer, sem staging em disco, sem commit assíncrono — só um stream direto entre dois sockets HTTP.

0 bytes em disco
03 · RECEPTOR

GET como stream

Da máquina de destino, o curl faz GET no caminho e canaliza a resposta por gunzip | psql. O stream do lado do receptor termina no segundo em que o último byte do remetente chega. Sem retry, sem manifesto, sem limpeza.

GET /api/v1/pipe/migration

A ordem das conexões não importa — o receptor pode fazer curl primeiro e bloquear até o remetente conectar (ou vice-versa), até o TTL de 5 minutos do pipe. O backpressure flui ponta a ponta: um psql lento freia o curl na origem. Não tem fila para transbordar porque não tem fila.

use-cases / move-200gb-between-clouds-with-two-curls / commands

Os dois comandos de verdade

Não é pseudocódigo. Abra dois terminais nas duas máquinas, rode um em cada, e veja um backup de 200GB sair de uma nuvem e chegar na outra.

frankfurt:~ · remetente
PUT · REMETENTEFrankfurt → pipe
# 1. Envie o banco vivo para o pipe$pg_dump --format=custom mydb | gzip \ | curl -T - https://pipe.containers.hoody.com/api/v1/pipe/migration# 2. O servidor responde com mensagens de status[INFO] Waiting for 1 receiver(s) to connect...[INFO] Streaming to 1 receiver(s)...[INFO] Upload complete.[INFO] Transfer complete.
singapore:~ · receptor
GET · RECEPTORpipe → Singapura
# 1. Mande direto para o novo banco$curl https://pipe.containers.hoody.com/api/v1/pipe/migration \ | gunzip | psql newdb# 2. Os bytes chegam ao psql conforme saem de FrankfurtCREATE TABLE okCOPY 4823918 okALTER TABLE ok

PUT (curl -T) é preferível porque é como o curl quer enviar um stream. POST funciona igual — mesmo caminho, mesmas mensagens de status. Use ?n=N nos dois lados se precisar fazer fan-out do mesmo dump para vários receptores.

use-cases / move-200gb-between-clouds-with-two-curls / spectator
PROGRESSO · ?progress

Uma URL de espectador que qualquer um pode acompanhar

Um terceiro notebook abre a mesma URL de pipe com ?progress e recebe um feed SSE em tempo real de bytes-por-segundo, ETA e receptores conectados. Acompanhar não consome um slot de receptor — cinquenta colegas podem ver a migração sem mudar o valor de n nem interferir na transferência.

  • SEM SLOT DE RECEPTOR
  • ATÉ 50 ESPECTADORES
  • PERMANÊNCIA DE 30 MIN
spectator.…hoody.com/migration?progress
SSE · text/event-streamSTREAMING
event: statedata: ["state":"streaming","receivers":1]event: progressdata: ["bytes":83_421_667_840, "speed":"412 MB/s", "eta":"4m 44s"]event: progressdata: ["bytes":118_295_117_824, "speed":"406 MB/s", "eta":"3m 21s"]↻ ao vivo · throttle de 250ms
use-cases / move-200gb-between-clouds-with-two-curls / why

Por que dois curls vencem seis passos

O round-trip de S3 parece simples no quadro branco. Em produção é uma pilha de partes móveis que cobram por segundo. O pipe colapsa a pilha inteira no próprio transporte.

Sem terceira camada de storage

S3, GCS, Azure Blob — o round-trip existe só porque não tinha outro lugar para parquear os bytes. O pipe é o caminho. Não tem bucket para provisionar, regra de lifecycle ou limpeza depois.

Pague pelo voo, não pelo repouso

Egress no upload, egress no download — duas vezes. Com o pipe os bytes saem de Frankfurt e chegam em Singapura num salto. Você paga pelos segundos em que a conexão ficou aberta, não pelo storage que vai apagar amanhã.

HTTP até embaixo

Seu monitoramento já entende HTTP. Sua VPN também, seu firewall, seu audit log. Sem identidade IAM nova, sem SDK novo, sem modo de falha novo — é um comando curl.

DIMENSÃOROUND-TRIP DE S3HOODY PIPE
  • Passos6 estágios2 curls
  • Disco usado200 GB0 bytes
  • Pernas de egress2 × 200 GB1 × 200 GB
  • Limpezaregra de lifecyclenenhuma

A velocidade é limitada pela ponta mais lenta de ponta a ponta (egress de Frankfurt, ingress de Singapura, sua janela TCP). O pipe da Hoody retém zero bytes — não há storage do lado do servidor; o backpressure flui direto entre os dois endpoints.

use-cases / move-200gb-between-clouds-with-two-curls / punchline

Dois terminais, uma URL, sem terceira camada de storage.

A migração inteira tem o mesmo formato de cat file | wc -l. O fato de os dois pipes morarem em data centers diferentes é um detalhe de implementação da URL.

  • zero saltos
  • zero retenção
  • uma URL
Ler a API
use-cases / move-200gb-between-clouds-with-two-curls / replaces

O que isto substitui

Qualquer coisa que existe só porque ninguém tinha um caminho HTTP que faz streaming. O pipe colapsa a pilha inteira de migração de dados em um curl de cada lado.

  • Cópia entre regiões do AWS S3Dois egresses, um bucket, regras de lifecycle
  • Transferência via Dropbox200 GB ficam no disco de outro por uma semana
  • Entrega via Google DriveParedes de cota, links de share, limpeza manual
  • rsync sobre SSHSSH entre nuvens aleatórias = bastions e troca de chaves
  • SCP + resumeUm processo, sem fan-out, quebra em links instáveis
  • Ferramentas terceirizadas de migraçãoFornecedor inteiro para um curl com passos extras
use-cases / move-200gb-between-clouds-with-two-curls / cta

Pule o bucket. O transporte é a URL.

Ler a pipe API
use-cases / move-200gb-between-clouds-with-two-curls / related

Leia os outros