Skip to main content

Module 4: Service Mesh

Overview​

You've added scheduling, autoscaling, and Gateway API to the Voting App. The next question isn't "how to add a service mesh" - it is "SHOULD you add one?" This module builds your decision-making muscle.

Service mesh is a crossroads decision in production readiness. Many teams adopt it prematurely, adding complexity without benefit. Others add it too late, missing observability and security gaps. This module teaches you when a service mesh adds value versus when it adds unnecessary overhead.

What You Will Learn​

  • What service mesh provides (mTLS, observability, traffic management)
  • When to adopt a service mesh based on your architecture and team
  • Istio vs Linkerd comparison with tradeoffs for each
  • Decision framework for mesh adoption with evaluation criteria
  • Optional hands-on with Linkerd to see mesh behavior in action

Metadata​

  • Difficulty: Intermediate-Advanced
  • Estimated Time: 80 minutes
    • Reading: 15 minutes
    • Lab: 50 minutes (evaluation exercise with optional hands-on)
    • Quiz: 15 minutes

Prerequisites​

  • Modules 0-3 completed (conceptual understanding of Voting App architecture)
  • kubectl and kind installed (already have KIND cluster running)
  • This module is evaluation-focused rather than implementation-focused - you'll build decision-making skills

Next Steps​

Start with the reading materials to understand service mesh concepts and the decision framework, then apply your knowledge in the lab evaluation exercise.