
Soixante conteneurs sur un seul serveur
Une machine bare-metal exécute des dizaines à des centaines de conteneurs Hoody. La dédupplication KSM et BTRFS rend le coût marginal quasi nul.
Le service A redirige sa sortie vers un chemin. Le service B la récupère depuis le même chemin. Le pipe achemine les octets entre les deux conteneurs en temps réel. Pas de Redis, pas de groupe de consommateurs, pas de daemon broker à entretenir.
POST in. GET out. The middle hop is a URL.
Deux verbes HTTP et un chemin. L'une ou l'autre extrémité peut se connecter en premier ; le pipe attend jusqu'à cinq minutes la contrepartie puis fait passer les octets. Pas de file, pas d'offset, pas de groupe.
Producteur hors ligne ? Le consommateur fait GET et attend. Consommateur hors ligne ? Le producteur fait PUT et attend. Le pipe maintient la connexion jusqu'à cinq minutes jusqu'à ce que la contrepartie arrive.
Quand le consommateur est lent, le kernel ralentit le flux du producteur. Pas de profondeur de file à monitorer, pas de high-watermark à régler. Le socket est le buffer.
Le compromis honnête : rien n'est persisté. Pour de la file durable, ce n'est pas la solution. Pour du fan-out conteneur-à-conteneur rapide, le broker vient de disparaître.
# Container A — producer streams jobs to the pipe
service-a | curl -T - https://api.hoody.com/api/v1/pipe/jobs
# Container 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 n'atterrissent sur aucun disque — ils traversent le câble du producteur au consommateur, le pipe les transmet en vol.
Quand un logger ou un collecteur de métriques a besoin des mêmes événements, augmentez ?n et ajoutez un curl. Pas de configuration broker, pas de groupe de consommateurs, pas de secret d'auth à faire tourner. Le nouveau lecteur existe simplement.
Un lecteur lent applique de la backpressure au producteur ; 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 — disparaît.
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, mot de passe ou fichier 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 les données en file.
TCP ralentit le producteur quand le consommateur le plus lent prend du retard. Pas de tableau de bord de lag parce qu'il n'y a pas de lag — juste un débit de flux.
Producteur et consommateur 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 s'effondre. Ce qui était un daemon stateful avec credentials, clients et runbook est désormais un chemin. Le diagramme d'architecture a une boîte de moins.
une URL, un curl, un verbe HTTP
L'infrastructure vers laquelle les équipes se tournent quand un conteneur doit passer des octets à un autre. Chacune ajoute un daemon, une config et une rotation d'astreinte. Le pipe ne facture rien de tout cela.
Monter Redis pour que deux conteneurs se parlent ? Ou partager une URL.