
Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
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.
200GB · zero saltos · zero retenção
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.
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/migrationQuando 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 discoDa 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/migrationA 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.
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.
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.
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.
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.
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.
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ã.
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.
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.
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.
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.
Pule o bucket. O transporte é a URL.