ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Sidecar

The auxiliary process glued to the application container — sharing localhost, memory or volume — to add cross-cutting capabilities without recompiling.

Problem

An AS2 connector written in Java 6 by a vanished vendor has run for 15 years. It is now asked to emit OpenTelemetry structured logs, encrypt with modern outbound mTLS, sign with SHA-256 instead of SHA-1, and expose Prometheus metrics. The source code is partially lost, the vendor is gone, the JDK is unsupported. Modifying the binary is risky: a regression costs a month of stalled INVOIC.

Forces

  • The application code is frozen. Either for contractual reasons (partner certification), technical (legacy binary), or organisational (team gone).
  • Cross-cutting needs evolve. mTLS, observability, compliance: standards change every two years.
  • Kubernetes deployment enables it. A Pod can host several containers sharing network and volumes — the technical foundation of the sidecar.
  • Operational overhead doubles. Two containers to monitor, two versions to keep in sync.

Solution

Deploy the application container and a sidecar container in the same Pod. The sidecar intercepts traffic (Envoy proxy in iptables redirect mode), reads log files via a shared volume, or exposes an API the main container calls on localhost. It carries cross-cutting concerns — mTLS termination, modern crypto signing, log shipping to Loki, OpenTelemetry tracing, EDI schema validation. The main container is untouched. 

┌──────────────────────────────────────────────────────┐
│  Kubernetes Pod                                      │
│ ┌─────────────────┐   localhost   ┌────────────────┐ │
│ │ App container   │ ────────────▶ │ Sidecar Envoy  │ │
│ │ EDI translator  │   :15001      │ mTLS + logs    │ │
│ │ Java / Python   │ ◀──────────── │ trace export   │ │
│ └─────────────────┘               └────────────────┘ │
│ shared volume /var/log/edi  ⟶  Fluent Bit sidecar    │
└──────────────────────────────────────────────────────┘
                       │
              Walmart partner (outbound mTLS)

EDI implementation

Concrete case: a legacy AS2 connector (old Sterling B2B) runs on port 8443 HTTP/1.1, signs in SHA-1. We deploy an Envoy sidecar in front that terminates modern mTLS (TLS 1.3, Let's Encrypt certs with 90-day rotation), rewrites AS2 headers, and publishes the receipt event on Kafka via a Lua filter. Walmart sees a modern endpoint; Sterling keeps parsing what it receives. Another case: a Fluent Bit sidecar tails the OFTP2 connector flat-file logs and ships them to Elastic — the connector does not know it is observed. Service Mesh (Istio, Linkerd) industrialises this at namespace scale.

Anti-patterns

  • Sidecar as a Swiss army knife. Putting mTLS + logs + cache + business logic in a sidecar — it becomes another coupled monolith. One sidecar = one cross-cutting responsibility.
  • Sidecar for code you can modify. If you control the application code, add OTEL/mTLS libraries directly — no need to introduce a doubled Pod.
  • Lifecycle coupling ignored. The sidecar restarts in a loop: the whole Pod restarts, app too. Test startup orchestration (init containers, readiness probes).
  • Ambassador — special case: the outbound proxy sidecar.
  • Adapter — special case: the sidecar normalising logs or metrics.
  • Service Mesh — industrialising the sidecar at cluster scale.
  • Smart Proxy — the Hohpe cousin, more ESB-oriented than cloud-native.

Sources