Istio vs Nix

Only if you have enough services, or a compliance requirement, that implementing mTLS, retries and tracing per language has become unmanageable. Below roughly a few dozen services, an ingress controller plus good client libraries usually delivers more reliability for less operational cost.

No. The package manager runs fine on any Linux distribution and on macOS, and most teams start there with development shells rather than converting their servers.

Ambient removes the per-pod proxy and its startup ordering problems and costs less at high pod counts, but it is a newer architecture and does not cover every sidecar feature. New deployments should evaluate ambient first; existing sidecar meshes should treat the move as a migration project.

It solves an adjacent problem. Nix reproduces the contents of an environment exactly; Docker distributes an image. Many teams use Nix to build the image.

Linkerd is deliberately smaller, uses its own Rust proxy rather than Envoy, and is quicker to operate; Istio has a far larger feature surface, multi-cluster and VM support, and broader vendor backing. Note that Linkerd's stable distribution builds are commercially licensed by Buoyant, whereas Istio's releases are freely available.

They are used in production widely and are stable in practice, but they remain officially experimental, which means the interface can still change and documentation is split.

Solo.io and Tetrate sell supported distributions and control planes, and Google offers Cloud Service Mesh as a managed option. The upstream project itself is CNCF-governed with community support.

Lix is a community fork of the Nix implementation created after governance disputes. It is largely compatible; the practical impact is that you must decide which implementation your team standardises on.

Partly. Virtual machine workloads can be added to a mesh, but the tooling, documentation and community experience are heavily Kubernetes-centred, so a VM-majority estate is fighting the grain of the project.