Microservices get oversimplified in most explanations. The real idea isn’t just “small services” – it’s independently deployable services that each own a single business capability and communicate over APIs. The independence is the point. A bug in your recording service shouldn’t bring down call routing. A team shipping a new feature to the analytics service shouldn’t require a coordinated release with three other teams. But getting there is harder than it sounds, and a lot of teams discover that the hard way.

The decomposition decision is primarily organisational, not technical. You split services along team boundaries and data ownership, not arbitrary technical layers. A contact centre platform might decompose into separate services for call routing, agent assignment, recording, real-time analytics, and customer history – each owned by a different team, each on its own deployment schedule. Kubernetes handles deployment and scheduling. A service mesh – Istio or Linkerd being the two main options – manages how those services talk to each other. Both inject a sidecar proxy (Envoy in Istio’s case) alongside each service pod, intercepting all network traffic, enforcing mTLS, applying traffic policies, and emitting telemetry to Prometheus and Jaeger. The key selling point: zero application code changes required. That’s genuinely useful. Istio has a steep learning curve though – most people underestimate it, and it’s added real operational burden for teams that jumped in without fully understanding what they were taking on.

The honest assessment of microservices in 2025-2026 is that real-world experience has tempered the early hype considerably. Distributed systems are genuinely harder to debug than monoliths. A single user request might touch 15 services, and tracing a failure across them requires distributed tracing tooling (Jaeger, Zipkin, or Tempo) and careful correlation ID propagation. Many teams – including some large ones – have found that starting with a modular monolith and extracting services only when a specific team or scaling need demands it produces better outcomes than decomposing everything upfront. That’s not a failure of the pattern – it’s a maturation of how it’s applied. And Cilium eBPF-based networking is worth watching: it achieves many of the same traffic management goals as a service mesh but at the kernel level, without sidecar injection, which means less overhead and simpler debugging.

Frequently Asked Questions

How do you decide how small a microservice should be?

A good heuristic: a service should do one thing well and be owned by one team. If two services are always deployed together, always fail together, or are always changed together, they should probably be one service. If making a simple change requires coordinating with three other teams, the service is probably too large.

What problems does a service mesh solve?

A service mesh handles cross-cutting concerns that would otherwise require every service team to implement themselves: mutual TLS for encryption, circuit breakers to prevent cascading failures, traffic shaping for canary deployments, and automatic metrics and trace collection – all moved out of application code into the infrastructure layer.

Is Istio still the best choice for a service mesh?

Istio is the most feature-complete option but carries significant operational complexity. Linkerd is a strong alternative with a simpler operational model and better performance for most use cases. Cilium with eBPF is increasingly popular because it achieves traffic management at the kernel level without sidecar proxies, reducing overhead and simplifying debugging.

What is the difference between microservices and serverless?

Microservices are long-running processes you deploy and manage as containers, typically on Kubernetes. Serverless functions are stateless, event-driven, and managed entirely by the cloud provider – you don’t think about instances or scaling. Many organisations use both: persistent microservices for core business logic and serverless for event-driven glue code and background processing.