Aller au contenu
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERPartager un flux
POURDevs backend
POURÉquipes de devs
SERVICESPipe
SERVICESConteneurs
POURQUOI HOODYHTTP-natif
POURQUOI HOODYÉconomie des conteneurs
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERPartager un flux
POURDevs backend
POURÉquipes de devs
SERVICESPipe
SERVICESConteneurs
POURQUOI HOODYHTTP-natif
POURQUOI HOODYÉconomie des conteneurs
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERPartager un flux
POURDevs backend
POURÉquipes de devs
SERVICESPipe
SERVICESConteneurs
POURQUOI HOODYHTTP-natif
POURQUOI HOODYÉconomie des conteneurs
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERPartager un flux
POURDevs backend
POURÉquipes de devs
SERVICESPipe
SERVICESConteneurs
POURQUOI HOODYHTTP-natif
POURQUOI HOODYÉconomie des conteneurs
PIPE · CONTAINER-À-CONTAINER

IPC inter-conteneur sans le broker

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.

Lire la doc pipe

Comment le pipe remplace le broker

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.

01 · HANDSHAKE

N'importe quel côté peut se connecter en premier

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.

02 · BACKPRESSURE

La connexion TCP est la queue

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.

03 · STATELESS

Oublie les messages une fois livrés

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.

producer.sh · consumer.sh
# 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.

Ajoutez un troisième lecteur. Puis un quatrième.

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.

pipe/jobs · lecteurs?n=4 · TOUT EN FAN-OUT
  • + AJOUTÉ
    consumer-aloggermetricsaudit
    curl ?n=4 — rejoint le fan-out
  • = STABLE
    producer
    service-a | curl -T - ?n=4
  • − RETIRÉ
    redisconsumer-group.ymlbroker.conf
    pas de broker, pas de config

Un lecteur lent applique de la backpressure au producer ; il ne bloque pas les autres. Jusqu'à 256 lecteurs par chemin.

Ce que l'URL vous donne et que le broker prenait

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.

  • Pas de daemon à opérer

    Rien à déployer, monitorer, ou upgrader. Le pipe est la plateforme ; l'URL est la seule API.

  • Bearer auth, pas des creds broker

    Un token Hoody, scopé par projet. Pas de username/password/ACL par broker.

  • Même câble, n'importe quelle langue

    Tout ce qui parle HTTP peut produire ou consommer — bash, Python, Go, un téléphone, un navigateur. Pas de bibliothèque cliente.

  • Pas d'état persisté

    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.

  • La backpressure est le protocole

    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.

  • Les conteneurs restent découplés

    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.

C'ÉTAIT LÀ
  • cluster redisauth, réplicas, failover
  • consumer-group.ymloffsets, partitions
  • SDK broker dans chaque servicelib cliente par langage
C'EST LÀ
/api/v1/pipe/jobs

une URL, un curl, un verbe HTTP

Lire la doc pipe

Ce que ça remplace

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.

  • Redis pub/subDaemon, auth, clients par langage
  • RabbitMQCluster à opérer pour des octets en vol
  • NATSEncore un protocole, encore un sidecar
  • ZeroMQBibliothèque dans chaque service, pas d'URL
  • Daemons de routing customService sur mesure à garder en vie
  • Services gRPC streamingSchéma, codegen, surcoût TLS mutuel
  • Brokers Apache KafkaCouche de stockage pour des messages que vous ne gardez pas

Monter Redis pour faire parler deux conteneurs ? Ou partager une URL.

Voir la pipe API

Lis les autres