Your platform runs Linkerd today, and a team asks for a mesh capability Linkerd does not have. How do you decide between working around it, putting the capability somewhere else in the stack, or migrating the mesh to Istio?

## Frame the question correctly first The common failure here is answering a feature-comparison question when you were asked a platform-strategy question. "Istio has X and Linkerd doesn't" is not a decision; it is an input. The decision is about where a capability should live and what changing the mesh costs the organisation. Start by classifying the request. ## Category 1: it is an edge concern wearing a mesh costume A large share of "we need Istio" requests are really requests for gateway behaviour: host and path routing with rich matching, request rewriting, external TLS certificates, WAF rules, authentication of end users at the perimeter, rate limiting by client. Linkerd's deliberate position is that this belongs to an ingress controller in front of the mesh, not to the sidecars. So the answer is to put the capability in the ingress tier — nginx, an Envoy-based ingress controller, or a cloud load balancer — and mesh that controller so traffic joins the mesh at the door. This is the highest-value move available to you, because it satisfies the requirement without touching the mesh at all. ## Category 2: Linkerd can do it, differently Some requests arrive phrased in Istio's vocabulary because that is what the team read about. Retries and timeouts, per-route golden metrics, weighted traffic splitting for a canary, service-to-service authorization based on workload identity — Linkerd has answers for all of these; they just are not called `VirtualService` or `DestinationRule`. Here the work is documentation and enablement, not migration. Say plainly: "you are asking for capability, not for a CRD name." ## Category 3: the real structural gaps These are the ones that would actually justify a mesh change, and you should be able to name them without hedging: - **Workloads outside Kubernetes.** Linkerd is a Kubernetes mesh. If you must mesh VMs or bare-metal services into the same trust and policy domain, that is a structural gap, not a configuration exercise. - **Per-request identity policy.** Validating end-user JWTs at the proxy and authorizing on claims is a different model from authorizing on workload mTLS identity. Linkerd's policy model is centred on workload identity and network scope; if you need per-request end-user policy in the data plane, look hard at whether it belongs at the edge instead — and if it genuinely must be everywhere, that is a real gap. - **Arbitrary L7 extensibility.** Wasm or Lua filters, protocol translation, bespoke in-proxy logic. Linkerd offers no extension point by design. - **Data-plane model.** If the requirement is a sidecar-less data plane for cost or lifecycle reasons, that is an architectural property, not a feature you can bolt on. ## Costing the migration honestly If you land in category three, price it before recommending it: - Every meshed pod must be re-injected and restarted — a fleet-wide rolling operation. - All mesh policy must be rewritten in a different model, and the two models do not map one-to-one. - Both meshes coexist during the transition, and cross-mesh traffic during that window is the hardest part of the plan. - Dashboards, alerts, runbooks and on-call knowledge are all mesh-specific and all get invalidated. - The steady-state operational surface grows. You very likely chose Linkerd because a small, boring mesh had fewer ways to fail at 3am; a migration spends that deliberately. A credible answer proposes a decision rule rather than a verdict: *does more than one team need the missing capability, is there no acceptable home for it outside the mesh, and is the requirement durable?* One team, one quarter, one workaround available means no migration. ## The alternatives to a full swap - **Put a second proxy in the path** for the one workload that needs the exotic behaviour — an Envoy-based gateway in front of that service — while the rest of the fleet stays on Linkerd. Two proxies on one path is ugly, but it is scoped and reversible. - **Move the concern into the application** where it is genuinely business logic that drifted into the platform. - **Run Istio only in the cluster or namespace that needs it**, accepting a heterogeneous platform. Costly in cognitive load, but occasionally the honest answer when one estate has genuinely different requirements. ## Also weigh the non-technical inputs At principal level, distribution and support terms are part of the decision: who publishes the builds you run, how upgrades are supported, what the release cadence and support window are for each project, and whether your organisation needs a commercial backing arrangement. These terms have changed for mesh projects before, so check the current state rather than reciting what was true a couple of years ago. The same applies to feature claims on both sides — data-plane models in this space move quickly, so verify against current releases before you commit a platform decision to a slide. ## What a strong answer sounds like "Tell me the capability, not the CRD. If it is edge behaviour it goes in the ingress tier. If Linkerd expresses it differently, we document it. If it is a structural gap that several teams need durably, I will cost a migration — fleet-wide re-injection, policy rewrite, dual-mesh window, retraining — and compare that against scoping Istio to the one estate that needs it."