Why Service mesh concept in Microservices? - Purpose & Use Cases

The Big Idea

What if your apps could talk perfectly without you fixing each conversation?

The Scenario

Imagine you have many small apps (microservices) talking to each other in a big system. You try to manage their communication by adding code to each app to handle retries, security, and monitoring.

The Problem

This manual way is slow and confusing. Each app needs extra code, which can cause mistakes and makes updates hard. If one app changes, you must fix many places. It's like fixing many broken pipes separately instead of having a central control.

The Solution

A service mesh adds a smart layer between apps to handle communication automatically. It manages retries, security, and monitoring without changing app code. This makes the system easier to manage and more reliable.

Before vs After

✗ Before

app.callService() with retry and security code inside

✓ After

app.callService() // service mesh handles retries and security

What It Enables

It lets teams focus on building features while the service mesh handles all the tricky communication details behind the scenes.

Real Life Example

Think of a delivery company where each driver manages their own routes and safety checks versus having a central system that plans routes, tracks packages, and ensures safety automatically.

Key Takeaways

Manual communication code in each microservice is hard to maintain.

Service mesh centralizes communication management without changing apps.

This leads to easier updates, better security, and reliable service connections.

Practice

1. What is the main purpose of a service mesh in microservices architecture?

easy

A. To write application business logic

B. To store data for microservices

C. To replace microservices with monolithic applications

D. To manage communication between microservices securely and reliably

Solution

1. Step 1: Understand the role of service mesh

   A service mesh handles how microservices talk to each other, focusing on communication.

2. Step 2: Identify what service mesh does not do

   It does not store data, replace microservices, or write business logic.

3. Final Answer:

   To manage communication between microservices securely and reliably -> Option D

4. Quick Check:

   Service mesh = communication management [OK]

Hint: Service mesh controls microservice communication, not data or logic [OK]

Common Mistakes:

• Confusing service mesh with data storage
• Thinking service mesh replaces microservices
• Assuming service mesh writes app code

2. Which of the following is a common tool used to implement a service mesh?

easy

A. Docker

B. Istio

C. Kubernetes

D. Git

Solution

1. Step 1: Recall popular service mesh tools

   Istio, Linkerd, and Consul are well-known service mesh tools.

2. Step 2: Differentiate from other tools

   Docker is for containers, Kubernetes for orchestration, Git for version control, not service mesh.

3. Final Answer:

   Istio -> Option B

4. Quick Check:

   Istio = service mesh tool [OK]

Hint: Istio is a popular service mesh tool, not Docker or Git [OK]

Common Mistakes:

• Choosing Docker or Kubernetes as service mesh
• Confusing version control tools with service mesh
• Mixing container tools with service mesh tools

3. Given a microservices setup with Istio service mesh, what happens when a service-to-service call fails due to network issues?

medium

A. Istio retries the call automatically based on configured policies

B. The call fails immediately without retries

C. Istio shuts down the service permanently

D. The service mesh ignores the failure and logs no information

Solution

1. Step 1: Understand Istio's retry feature

   Istio can automatically retry failed calls to improve reliability.

2. Step 2: Eliminate incorrect behaviors

   Istio does not shut down services or ignore failures silently; it logs and manages retries.

3. Final Answer:

   Istio retries the call automatically based on configured policies -> Option A

4. Quick Check:

   Istio retries failed calls = true [OK]

Hint: Istio retries failed calls automatically if configured [OK]

Common Mistakes:

• Assuming no retries happen on failure
• Thinking Istio shuts down services on failure
• Believing failures are ignored silently

4. You deployed a service mesh but notice that traffic between microservices is not encrypted. What is the most likely cause?

medium

A. The network cables are unplugged

B. The microservices are not running

C. Mutual TLS (mTLS) is not enabled in the service mesh configuration

D. The service mesh is not installed

Solution

1. Step 1: Check encryption settings in service mesh

   Service mesh uses mutual TLS (mTLS) to encrypt traffic between services.

2. Step 2: Identify why encryption might fail

   If mTLS is not enabled, traffic remains unencrypted despite service mesh presence.

3. Final Answer:

   Mutual TLS (mTLS) is not enabled in the service mesh configuration -> Option C

4. Quick Check:

   mTLS disabled = no encryption [OK]

Hint: Enable mTLS to encrypt service mesh traffic [OK]

Common Mistakes:

• Assuming services not running causes no encryption
• Thinking service mesh absence causes partial encryption
• Ignoring mTLS setting importance

5. You want to add observability to your microservices without changing their code. How does a service mesh help achieve this?

hard

A. By injecting sidecar proxies that monitor and report traffic metrics transparently

B. By rewriting the microservices code to add logging

C. By replacing microservices with a single monolithic app

D. By disabling network communication between services

Solution

1. Step 1: Understand sidecar proxy role in service mesh

   Service mesh injects sidecar proxies alongside microservices to handle communication and monitoring without code changes.

2. Step 2: Eliminate incorrect options

   Service mesh does not rewrite code, replace microservices, or disable communication.

3. Final Answer:

   By injecting sidecar proxies that monitor and report traffic metrics transparently -> Option A

4. Quick Check:

   Sidecar proxies add observability without code change [OK]

Hint: Sidecar proxies add monitoring without changing app code [OK]

Common Mistakes:

• Thinking code must be rewritten for observability
• Confusing service mesh with app replacement
• Assuming communication is disabled for observability