Your platform already runs Consul for service discovery and now needs a service mesh. What would make you turn on Consul's own mesh rather than adopt Istio, and where does Consul's model cost you by comparison?

## Start by discarding the false differentiator Both meshes run Envoy in the data plane. Latency overhead, memory per sidecar, the class of bugs you hit under load, the way a proxy behaves when the control plane is unreachable — those are broadly comparable and are not where the decision lives. The decision lives in three places: the shape of your estate, who operates the control plane, and how rich your policy needs to be. ## Estate shape: the strongest argument for Consul Consul's identity comes from its own catalog. A service is a catalog entry with a SPIFFE identity naming a namespace, datacenter and service, and that works identically for a process on a VM, a container on bare metal, and a pod in a cluster. Istio's identity is anchored in Kubernetes ServiceAccounts; workloads outside a cluster are supported, but they are onboarded as a special case rather than as the native model. So the question to ask is blunt: **is everything in Kubernetes, and will it be in two years?** If yes, the Consul advantage largely evaporates. If you have a substantial VM estate, multiple clusters that must talk to each other, or a migration that will take years, one catalog and one trust domain spanning all of it is a genuine architectural simplification — and if you are already running Consul for discovery, you are turning on a capability rather than introducing a whole new control plane with its own upgrade cadence and on-call. ## Operational cost: the strongest argument against Consul servers form a Raft cluster. You size it, spread it across failure domains, upgrade it carefully, snapshot it, and watch the leader — and the mesh depends on it for signing certificates and distributing configuration. That is a stateful distributed system you own, and it will occasionally be the thing that pages you. Istio's control plane is stateless and stores its configuration in the Kubernetes API server. If you run Kubernetes at all, you already operate that etcd cluster and its backups, so istiod adds a deployment rather than a new datastore. For a team whose entire world is one cluster, that difference is not academic; it is a whole class of operational burden that simply does not appear. ## Policy expressiveness Consul's intentions are deliberately small: a destination, a list of sources, allow or deny, with optional per-request permissions when the protocol is declared as HTTP. That smallness is a feature — the rules are readable, and a reviewer can tell what a change does. Traffic shaping lives in a separate, ordered set of entries (router, splitter, resolver) that compile into a discovery chain. Istio's vocabulary is larger. Its authorization resources reach further into request-level identity, notably validating JWTs and authorizing on their claims, and it exposes extension points for external authorization. If your policy requirements are "service A may call service B" plus a little path matching, Consul covers them and Istio's extra surface is cost. If they include end-user identity propagated in tokens, or an existing external policy engine you must integrate, Istio's model is closer to what you need out of the box. ## Configuration and workflow Istio is CRD-native, so everything is a Kubernetes object and ordinary GitOps applies with no extra thought. Consul's config entries are HCL or JSON written through `consul config write` or its API; on Kubernetes it also offers CRDs, but on VMs you need a delivery path of your own. A platform whose entire delivery model is "reconcile Kubernetes manifests from git" pays a small tax to hold Consul entries the same way. ## Ecosystem gravity This matters more than architects like to admit. Istio has the larger community, more third-party integrations, more hiring familiarity, and it is where sidecar-less/ambient data-plane work has had the most attention — a direction that changes the per-pod cost of a mesh materially. Consul's mesh is a smaller ecosystem, and choosing it means fewer people arriving already knowing it. Weigh that against the equally real cost of running two control planes if you keep Consul for discovery *and* add Istio for mesh. ## How to frame the decision Name the deciding facts rather than the feature comparison: how much of the estate is outside Kubernetes and for how long; whether you already operate Consul servers well; whether policy needs end-user token claims; who will be on call for the control plane. Then, whichever way it goes, make the reversible parts reversible — keep application code free of mesh assumptions, keep timeout and retry behaviour understood at the application level too, and adopt incrementally with a permissive posture before enforcing default deny. The mesh you can back out of is worth more than the one with the better feature matrix.