Service meshes are everywhere. Istio. Linkerd. Consul Connect. Every microservices architecture needs one. Or so the marketing says.

But here’s the thing: service meshes add sidecar proxies to every pod. Envoy, Istio’s sidecar, uses 50-200 MB RAM per pod. Linkerd-proxy uses 20-100 MB. Multiply by hundreds of pods. That’s gigabytes of memory just for service mesh overhead.

All of this before your applications run. All of this just for inter-service communication. All of this overhead.

The Sidecar Tax

Every pod gets a sidecar proxy. Envoy. Linkerd-proxy. Consul agent. Each one consumes CPU and memory. Each one adds latency. Each one is another thing that can break.

Envoy uses 50-200 MB RAM per pod. Plus CPU for proxying requests. Plus network overhead. Linkerd-proxy uses 20-100 MB. Consul Connect uses 30-150 MB.

A cluster with 100 pods: 2-20 GB RAM just for sidecars. A cluster with 1000 pods: 20-200 GB RAM. That’s a lot of overhead.

Teams add service meshes “because we need zero-trust.” But zero-trust doesn’t require service meshes. Application-level security works fine. TLS between services works fine. Service meshes are overkill for most teams.

The mTLS Overhead

Service meshes use mTLS for inter-service communication. Every request gets encrypted and decrypted. CPU overhead. Latency overhead. Complexity overhead.

mTLS adds 1-5ms latency per request. For high-traffic services, that’s significant. Millions of requests per day. Each one slower. Each one consuming more CPU.

Application-level TLS is simpler. Libraries handle it. No sidecars. No service mesh. Just TLS between services. That’s enough for most teams.

But service mesh marketing says you need mTLS everywhere. You need zero-trust. You need service mesh. But do you?

The Complexity Explosion

Service mesh configs are complex. Virtual services. Destination rules. Traffic policies. Retry policies. Circuit breakers. The list goes on.

Istio configs can be hundreds of lines. Teams spend weeks configuring service meshes. Weeks debugging service mesh issues. Weeks understanding how service meshes work.

All of this complexity. All of this operational burden. All for inter-service communication that most teams can handle with simpler mechanisms.

Application-level load balancing works fine. Application-level retries work fine. Application-level circuit breakers work fine. You don’t need a service mesh for these.

The “Zero-Trust” Marketing

Service mesh marketing focuses on zero-trust. “You need mTLS everywhere.” “You need service mesh for security.” “You can’t trust your network.”

But zero-trust doesn’t require service meshes. Application-level security works fine. Network-level security works fine. Service meshes are one way to implement zero-trust. Not the only way.

Teams choose service meshes “because we need zero-trust.” But they don’t need service meshes for zero-trust. They need security. Service meshes are one option. Not the only option.

The Observability Promise

Service meshes promise observability. Automatic tracing. Automatic metrics. Automatic logging. But you can get these without service meshes.

Application-level instrumentation works fine. OpenTelemetry. Prometheus. Structured logging. These provide observability without service mesh overhead.

Service meshes add observability, but at a cost. Sidecar overhead. Configuration complexity. Operational burden. Is it worth it?

For most teams, no. Application-level observability is simpler. It’s cheaper. It’s enough.

Real Teams Removing Service Meshes

I know teams that removed Istio. They moved to application-level TLS. They moved to application-level load balancing. They moved to application-level observability.

Result: 20-30% reduction in resource usage. Simpler architecture. Faster requests. Lower operational overhead.

The pattern: add service mesh “because everyone does it.” Discover the overhead. Remove it when possible. But nobody writes blog posts about removing service meshes because it’s embarrassing to admit you didn’t need it.

Who Actually Needs It

Service meshes make sense if you have:

  • Complex microservices architectures with hundreds of services
  • Need for advanced traffic management (A/B testing, canary deployments)
  • Multiple teams that need independent service policies
  • Compliance requirements that service meshes meet
  • Teams that can operate service meshes effectively

Most teams don’t have these requirements. Most teams have simple microservices architectures. Most teams can handle inter-service communication with simpler mechanisms.

If you’re running fewer than 20 services, service meshes are probably overkill. If you don’t need advanced traffic management, service meshes are probably overkill. If you can’t operate service meshes, service meshes are definitely overkill.

The Honest Answer

I genuinely don’t know how to feel about service meshes. They solve real problems for complex architectures. But most architectures aren’t complex.

The honest answer: if you’re running fewer than 20 services, skip the service mesh. Use application-level TLS. Use application-level load balancing. Use application-level observability. It’s simpler. It’s cheaper. It’s enough.

If you need advanced traffic management, service meshes might make sense. But most teams don’t need advanced traffic management. Most teams need simple inter-service communication. And that doesn’t require a service mesh.

The goal is to connect services, not to operate the most sophisticated service mesh. Service meshes are a tool. They’re not a requirement. And for most teams, they’re unnecessary overhead.

Service mesh marketing says you need zero-trust. You need mTLS everywhere. You need service mesh. But you don’t. Application-level security works fine. Network-level security works fine. Service meshes are one option. Not the only option.

Most teams can skip service meshes. Most teams can use simpler mechanisms. Most teams can avoid the sidecar tax entirely.

But if you’re running complex microservices architectures with hundreds of services, service meshes might make sense. Just understand what you’re paying for. Understand the overhead. Understand that most teams don’t need what service meshes provide.