I'm migrating a legacy monolithic application to a microservices architecture and have chosen Kubernetes for orchestration. I've set up a basic cluster and can deploy services, but I'm struggling with designing an effective ingress strategy for internal service-to-service communication alongside external user traffic. I'm unsure whether to use a service mesh like Istio or rely on native Kubernetes services and ingress controllers, as the complexity and overhead of a full mesh seems daunting for a small team. What are the key decision factors for choosing between these approaches in a production environment with around twenty services?
In a 20-service setup, a full Istio mesh is often more overhead than you need unless you require strict mTLS and advanced traffic management.
Key decision factors: security requirements (mTLS, service identity), traffic control (canary, fault injection), observability (distributed tracing, metrics), operational readiness (team skills, SRE practices), scale/east-west traffic needs, multi-cluster/geo distribution, and cost/complexity.
If you pick a mesh, consider Linkerd for simplicity or Istio for features; test with a small pilot (3-5 services) and measure ROI before expanding.
Recommended pragmatic plan: start with native Kubernetes for internal service discovery and an Ingress controller for external traffic; ensure TLS termination and cert-manager; monitor; then if needed, roll out mesh gradually focusing on service-to-service encryption first (mTLS) and then traffic shaping features; keep a clear upgrade path.
Other approach: use a 'mesh-lite' approach: a simple sidecar per service using a lighter proxy (like Linkerd's own).
Discuss multi-cluster support early if you anticipate geographic distribution; many teams start with a single cluster; cross-cluster traffic is trickier.
If you share whether you already have strong observability (OpenTelemetry, Jaeger) and whether you need east-west security, I can tailor a deployment plan and the minimal set of features needed.