Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
Le service A pipe sa sortie vers un chemin. Le service B tire depuis le même chemin. Le pipe route les octets entre les deux conteneurs en temps réel. Pas de Redis, pas de consumer group, pas de daemon broker à materner.
POST entrant. GET sortant. Le saut du milieu est une URL.
Deux verbes HTTP et un chemin. N'importe quel côté peut se connecter en premier ; le pipe attend jusqu'à cinq minutes le partenaire puis stream les octets. Pas de queue, pas d'offset, pas de groupe.
Producer offline ? Le consumer GET et attend. Consumer offline ? Le producer PUT et attend. Le pipe garde la connexion jusqu'à cinq minutes le temps que le partenaire arrive.
Quand le consumer est lent, le noyau ralentit le stream du producer. Pas de profondeur de queue à monitorer, pas de high-watermark à régler. Le socket est le buffer.
Le compromis honnête : rien n'est persisté. Pour de la queue durable, ce n'est pas ça. Pour du fan-out conteneur-à-conteneur rapide, le broker vient de disparaître.
# Conteneur A — producer streams jobs to the pipe
service-a | curl -T - https://api.hoody.com/api/v1/pipe/jobs
# Conteneur B — consumer reads from the same path
curl https://api.hoody.com/api/v1/pipe/jobs | service-b
# Either side can connect first.
# The pipe holds the connection up to 5 minutes
# until the counterpart arrives, then streams through.PUT (ou POST) envoie. GET reçoit. Les octets ne touchent aucun disque — ils traversent le câble du producer au consumer avec le pipe qui transmet en vol.
Quand un logger ou un collecteur de métriques a besoin des mêmes events, monte ?n et ajoute un curl. Pas de config broker, pas de consumer group, pas de secret d'auth à roter. Le nouveau lecteur existe, c'est tout.
Un lecteur lent applique de la backpressure au producer ; il ne bloque pas les autres. Jusqu'à 256 lecteurs par chemin.
Le broker existait parce que deux conteneurs ne pouvaient pas se parler directement. Avec le pipe, ils le peuvent. Tout ce que le broker ajoutait — auth, clients, ops — tombe.
Rien à déployer, monitorer, ou upgrader. Le pipe est la plateforme ; l'URL est la seule API.
Un token Hoody, scopé par projet. Pas de username/password/ACL par broker.
Tout ce qui parle HTTP peut produire ou consommer — bash, Python, Go, un téléphone, un navigateur. Pas de bibliothèque cliente.
Les messages vivent en vol, pas au repos. Pas de disque à remplir, pas de politique de rétention, pas de question RGPD sur des données en queue.
TCP ralentit le producer quand le consumer le plus lent prend du retard. Pas de dashboards de lag parce qu'il n'y a pas de lag — juste un débit de stream.
Producer et consumer ne voient jamais leurs IPs respectives. Ils partagent une URL. Déplacez l'un ou l'autre vers un autre hôte sans recâbler.
Le broker est l'URL. L'URL est le broker.
La couche du milieu collapse. Ce qui était un daemon stateful avec credentials, clients, et runbook devient un chemin. Le schéma d'architecture a une boîte de moins.
une URL, un curl, un verbe HTTP
L'infra que les équipes attrapent quand un conteneur doit passer des octets à un autre. Chacune ajoute un daemon, une config, et une astreinte. Le pipe ne vous facture rien de tout ça.
Monter Redis pour faire parler deux conteneurs ? Ou partager une URL.