Sidecar vs Sidecarless

The Three Shapes

 SIDECAR (classic):
   proxy container in EVERY pod. dedicated, isolated, uniform.

   [pod: app + proxy] × N pods

 SIDECARLESS / AMBIENT (node-shared):
   node-level L4 tunnel (ztunnel-class) + optional L7 waypoints:

   [node: ztunnel ◄─ pod pod pod] + waypoint where needed

 eBPF-BASED (kernel dataplane):
   kernel handles forwarding/parsing; envoy only when L7 policy:

   [node kernel: fast path] → [envoy: only for L7 rules]

The Decision Matrix

Dimension	Sidecar	Sidecarless/Ambient	eBPF
Resource overhead	highest (per-pod)	low (shared/node)	lowest
Upgrade blast radius	every pod restarts	node components roll	kernel+agent rolls
Isolation per workload	strongest	compartmentalized	compartmentalized
L7 policy maturity	mature everywhere	waypoint opt-in	maturing
Protocol coverage beyond HTTP	weak	weak	strong (sql/redis)
Maturity/operational history	years, battle-worn	newer, converging	youngest dataplane
Debugging familiarity	pod-local logs	split node/waypoint	kernel tooling skills

Choosing by Estate Profile

 STAY sidecar:
 □ compliance narratives demand per-workload isolation
 □ uniform heavy L7 policy fleet-wide already the norm
 □ operational playbooks/team skills fully sidecar-tuned

 MOVE sidecarless:
 □ mesh resource tax dominates complaints at 1000s of pods
 □ most namespaces need only mTLS+identity (L4 truth!)
 □ upgrade waves of every pod hurt release velocity

 CONSIDER eBPF-first:
 □ protocol diversity (databases, caches, queues) matters
 □ performance floors are strict; tail-latency budgets tight
 □ kernel versions modern + team has (or will build) skill

 HYBRIDS ARE NORMAL: sidecars on critical L7-heavy services,
 ambient for the long tail — coexistence is designed-in.

Migration Realities

 switching shapes is a PROJECT, not a flag:

 □ IDENTITY continuity: workload identities must survive
   the transition (trust domain planning first)
 □ POLICY translation: sidecar-era configs rarely map 1:1;
   inventory and re-express policies deliberately  
 □ TELEMETRY dashboards change shape: metric sources move;
   alerting must be re-verified against new series
 □ ROLLBACK story per namespace: keep both paths runnable
   during transition windows
 □ GAME DAYS before cutover of critical namespaces —
   failure modes genuinely differ between shapes

 sequencing that works: non-critical namespace pilot →
 metrics parity review → wave-by-wave with rollback hatches.

Signal you chose wrong	Correction direction
nodes 30% consumed by proxies	→ sidecarless
audit demands per-pod isolation proofs	→ sidecar
can’t see database traffic ever	→ add eBPF lens
team debugging kernel traces weekly unhappily	← away from eBPF

Interview Framing

“Design the data-plane strategy for a 3000-pod estate with mixed needs” scored shape: three shapes presented via decision matrix, profile-based verdicts (not fashion), hybrid-coexistence endorsed explicitly, migration mechanics named (identity/policy/telemetry continuity), rollback-per-namespace discipline shown. This question grades ARCHITECTURAL JUDGMENT under tradeoffs — the correct answer is always conditional; candidates who pick a winner universally reveal limited operational imagination.