Service Mesh: A Senior Software Engineer’s Guide (With Kuma as an Example)
#programming#softwaredevelopment#learning#cloudnative
Odumosu Matthew

Odumosu Matthew @iamcymentho

About: I'm currently deepening my expertise in Amazon Web Services (AWS) to strengthen my backend development skills. Given AWS's central role in modern infrastructure and cloud-native architecture, I see it

Location:
Lagos, Nigeria
Joined:
Jul 26, 2023

Service Mesh: A Senior Software Engineer’s Guide (With Kuma as an Example)

Publish Date: Jul 7
2 0

As a Senior Software Engineer, you’ve probably dealt with the challenges of microservices; service discovery, load balancing, observability, and security. Managing these concerns in a distributed system can be messy if each service has to handle them independently.

Enter Service Mesh a dedicated infrastructure layer that handles service-to-service communication so you don’t have to. Think of it like traffic control for microservices: instead of every service reinventing the wheel for retries, timeouts, or encryption, the service mesh takes care of it transparently.

1. What is a Service Mesh? (The Traffic Cop Analogy)

Imagine a busy city intersection:

  • Without a traffic cop, every driver (microservice) must independently decide when to go, stop, or yield. Chaos ensues.

  • With a traffic cop (service mesh), drivers just follow the road, the cop (sidecar proxy) handles signals, reroutes traffic, and prevents accidents.

Key Components of a Service Mesh

1. Data Plane – The "workers" (e.g., Envoy, Kuma’s DP) that handle actual traffic between services.

2. Control Plane – The "brain" (e.g., Kuma CP) that configures policies (retries, timeouts, ACLs).

Why Not Just Use API Gateways or Libraries?

  • API Gateways (like Kong) handle north-south traffic (client-to-service).

  • Service Mesh handles east-west traffic (service-to-service).

  • Libraries (like Netflix Hystrix) require code changes; a mesh works transparently.

2. Why Should You Care? (Real-World Pain Points)

Problem 1: "Why is Service A timing out when calling Service B?"

  • Without a mesh: You manually add retries, circuit breakers in code.

  • With a mesh: Auto-retries, timeouts, and circuit breaking are policy-based.

Problem 2: "How do we enforce mTLS across all services?"

  • Without a mesh: You configure TLS in each service (nightmare at scale).

  • With a mesh: Automatic mutual TLS between services.

Problem 3: "Who changed this API? Why is latency spiking?"

  • Without a mesh: You rely on logs, metrics scattered everywhere.

  • With a mesh: Unified observability (traces, logs, metrics).

3. Kuma: A Simple, Yet Powerful Service Mesh

Kuma is an open-source service mesh by Kong (makers of the Kong API Gateway). It’s platform-agnostic (Kubernetes, VMs, hybrid) and easy to adopt incrementally.

Key Features
✅ Multi-zone & Multi-cloud support (unlike Istio, which is K8s-heavy).
✅ Built on Envoy (high-performance data plane).
✅ Policy-driven (retries, traffic routing, ACLs via YAML/API).
✅ GUI & CLI support (Kuma Dashboard for visibility).

Example: Deploying Kuma on Kubernetes

Step 1: Install Kuma

kubectl apply -f https://bit.ly/kuma-ingress-demo
Enter fullscreen mode Exit fullscreen mode

Step 2: Define a Traffic Permission (mTLS Example)

apiVersion: kuma.io/v1alpha1  
kind: TrafficPermission  
mesh: default  
metadata:  
  name: allow-all  
spec:  
  sources:  
    - match:  
        kuma.io/service: '*'  
  destinations:  
    - match:  
        kuma.io/service: '*'
Enter fullscreen mode Exit fullscreen mode

This allows all services to talk securely via mTLS.

Step 3: Apply a Retry Policy

apiVersion: kuma.io/v1alpha1  
kind: Retry  
mesh: default  
metadata:  
  name: api-retries  
spec:  
  sources:  
    - match:  
        kuma.io/service: 'frontend'  
  destinations:  
    - match:  
        kuma.io/service: 'backend'  
  conf:  
    http:  
      numRetries: 3  
      timeout: 2s
Enter fullscreen mode Exit fullscreen mode

Now, if frontendcalls backend and fails, it automatically retries 3 times.

4. When Should You Use a Service Mesh?
✔ You have 10+ microservices (manual communication management is painful).
✔ You need observability (distributed tracing, metrics, logging).
✔ Security is critical (mTLS, ACLs without code changes).

When NOT to Use a Service Mesh?
❌ Monolithic apps (overkill).
❌ Very small microservices setups (unless you plan to scale).

Conclusion

A service mesh is like adding air traffic control to your microservices, it doesn’t change how you build services, but it makes communication safer, faster, and observable.

Kuma is a great choice because:

  • It’s simple (easier than Istio).

  • It works anywhere (K8s, VMs, hybrid).

  • It scales with zero code changes.

LinkedIn Account : LinkedIn
Twitter Account: Twitter
Credit: Graphics sourced from DataScientest

Comments 0 total

    Add comment