ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

Adapter (cloud-native)

Standardiser ce qu'un conteneur expose vers l'extérieur — logs, métriques, santé — pour le rendre lisible par l'écosystème Kubernetes natif sans toucher au code.

Problème

Un connecteur EDIFACT propriétaire produit des logs .txt flat dans /var/log/edi/connector.log, expose ses métriques en JMX sur le port 9999, et propose un endpoint /status qui renvoie un mini-HTML coloré pour les ops. Pour intégrer ce service dans une stack moderne — Prometheus pour les métriques, Loki pour les logs, kubelet probes pour la santé — il faut adapter ces trois interfaces. Recompiler le binaire est impossible (vendor disparu).

Forces

  • Les standards de l'écosystème sont fixes. Prometheus exige /metrics en format texte name{label="value"} 42. OpenTelemetry exige du JSON structuré.
  • Le conteneur applicatif est figé. Modifier le format en sortie est exclu — soit code source perdu, soit certification partenaire bloquée.
  • L'adapter doit être passif. Pas de transformation métier, pas d'altération du comportement — juste la traduction de l'interface technique.
  • La latence ajoutée doit être négligeable. Un scrape Prometheus toutes les 15s tolère 50ms d'overhead, pas 5s.

Solution

Greffer un sidecar adapter dans le Pod. Il lit en input le format propriétaire — file tail, scrape JMX, HTTP polling — et l'expose en output au format standardisé attendu. Les binaires standards existent : jmx_exporter (Java → Prometheus), fluent-bit (logs → JSON OTel), cloudwatch-agent. Sinon, un petit programme Go ou Python suffit. L'adapter est stateless, son seul rôle est la traduction d'interface.

┌──────────────────────────────────────────────────────────┐
│  Pod                                                     │
│ ┌─────────────────┐                ┌───────────────────┐ │
│ │ Connecteur AS2  │                │ Adapter sidecar   │ │
│ │ legacy          │ JMX :9999 ───▶ │ JMX → Prometheus  │ │
│ │ /var/log/edi/   │ ─────fichiers─▶│ tail → JSON OTel  │ │
│ │ /status custom  │ ─────HTTP────▶ │ /healthz standard │ │
│ └─────────────────┘                └─────────┬─────────┘ │
└──────────────────────────────────────────────│───────────┘
                                               ▼
                          Prometheus / Loki / Kubernetes probe

Implémentation EDI

Cas concret : connecteur AS2 Java legacy expose JMX. On greffe jmx_exporter en sidecar, configuré via YAML pour publier edi_messages_total, edi_mdn_pending, edi_partner_latency_seconds en format Prometheus sur le port 9091. Le scrape Kubernetes Service Monitor récupère les métriques. Côté logs : le connecteur écrit connector.log en plain text — un sidecar Fluent Bit avec parser regex extrait partnerId, messageType, level, et émet du JSON structuré vers Loki. Côté health : un petit sidecar HTTP qui interroge l'URL /status custom toutes les 5s, parse le HTML, renvoie 200 ou 503 sur /healthz exposé au kubelet.

Anti-patterns

  • Adapter qui transforme la sémantique. Renommer des métriques pour les faire correspondre à un dashboard : pollue la donnée. L'adapter doit préserver fidèlement, pas réinterpréter.
  • Adapter qui devient un cache. Si l'adapter bufférise et perd des messages en cas de crash, on a un nouveau point de défaillance. Préserver la sémantique exactly-once-or-not du conteneur d'origine.
  • Plusieurs adapters concurrents. Adapter logs + adapter métriques + adapter santé : empilage de sidecars, coût Pod inflationniste. Regrouper si possible.

Patterns liés

  • Sidecar — pattern parent.
  • Ambassador — frère sortant ; l'adapter est plutôt entrant/exposition.
  • Normalizer — le cousin EIP pour la normalisation de format message-level.
  • Message Translator — la translation au niveau métier.

Sources

  • Burns B., Oppenheimer D.Design Patterns for Container-based Distributed Systems, HotCloud 2016. Source académique du trio sidecar / ambassador / adapter cloud-native. usenix.org — HotCloud 2016
  • Microsoft Architecture Center — Cloud Native patterns. learn.microsoft.com — Cloud Native
  • Prometheus — JMX Exporter. L'adapter de référence Java → Prometheus. github.com/prometheus/jmx_exporter
  • Fluent Bit — Log adapter. La référence open-source pour adapter des logs hétérogènes à des formats standards. fluentbit.io
  • Gamma E., Helm R., Johnson R., Vlissides J.Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley 1994. Le pattern Adapter originel (objet) dont le pattern cloud-native est l'analogue à l'échelle conteneur.