Service mesh vs library-based approach in Kubernetes - Visual Side-by-Side Comparison

Process Flow - Service mesh vs library-based approach

Start: Application Service

↓

Direct Service Calls

↓

Service Communication

↓

Service Mesh Control Plane

↓

Configuration & Policy

Shows how library-based approach integrates proxies inside app code, while service mesh uses sidecar proxies to intercept calls, enabling features via a control plane.

Execution Sample

Kubernetes

app -> library proxy -> service
app -> sidecar proxy -> service
sidecar proxy -> control plane

Shows the flow of service calls through library proxy vs sidecar proxy in service mesh.

Process Table

Step	Component	Action	Result	Notes
1	Application	Calls service via library proxy	Request sent directly with embedded proxy logic	Library proxy is part of app code
2	Library Proxy	Processes request	Request forwarded to target service	No separate container involved
3	Application	Calls service	Request sent to sidecar proxy container	In service mesh, proxy runs separately
4	Sidecar Proxy	Intercepts and processes request	Applies policies, telemetry, security	Transparent to app
5	Sidecar Proxy	Forwards request to target service	Service receives request	Service unaware of proxy
6	Sidecar Proxy	Reports metrics to control plane	Control plane updates state	Enables centralized management
7	Control Plane	Sends config and policies	Sidecar proxies update behavior	Dynamic and centralized
8	Application	Receives response	Response returned to app	Same for both approaches
9	End	No more steps	Communication complete	Process repeats for each call

💡 Communication ends after response is received by application

Status Tracker

Component	Start	After Step 1	After Step 3	After Step 4	After Step 6	Final
Application	Idle	Request sent via library proxy	Request sent to sidecar proxy	Waiting for response	Waiting for response	Response received
Library Proxy	Inactive	Processing request	N/A	N/A	N/A	Idle
Sidecar Proxy	Inactive	N/A	Intercepting request	Applying policies	Reporting metrics	Idle
Control Plane	Idle	Idle	Idle	Idle	Updating config	Idle

Key Moments - 3 Insights

Why does the sidecar proxy run as a separate container instead of inside the app?

Because the sidecar proxy is independent, it can be updated or managed without changing the app code, as shown in execution_table steps 3 and 4.

How does the library-based approach affect the application code?

The library proxy is embedded inside the app, so the app code must include proxy logic, seen in execution_table step 1.

What role does the control plane play in the service mesh?

The control plane manages configuration and policies centrally, updating sidecar proxies dynamically, as shown in steps 6 and 7.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the sidecar proxy apply policies to the request?

A Step 2

B Step 4

C Step 6

D Step 8

💡 Hint

Check the 'Action' column for sidecar proxy activities in execution_table rows

According to variable_tracker, what is the state of the library proxy after step 1?

A Idle

B Intercepting request

C Processing request

D Reporting metrics

💡 Hint

Look at the 'Library Proxy' row under 'After Step 1' in variable_tracker

If the control plane stops sending config, which step in execution_table would be affected?

A Step 7

B Step 4

C Step 5

D Step 9

💡 Hint

Refer to the 'Control Plane' actions in execution_table step 7

Concept Snapshot

Service mesh uses sidecar proxies as separate containers to intercept service calls,
allowing centralized control and features without changing app code.
Library-based approach embeds proxy logic inside the app, requiring code changes.
Service mesh control plane manages policies and config dynamically.
Sidecar proxies report telemetry and enforce security transparently.
Library proxies handle requests directly within the app process.

Full Transcript

This visual execution compares service mesh and library-based approaches for managing service communication in Kubernetes. The library-based proxy is part of the application code and processes requests directly, requiring app changes. The service mesh uses sidecar proxies running as separate containers that intercept calls transparently, applying policies and reporting metrics to a control plane. The control plane centrally manages configuration and policies, updating sidecars dynamically. The execution table traces each step from the application sending requests through proxies to the service and back. The variable tracker shows component states changing over time. Key moments clarify why sidecars run separately, how library proxies affect app code, and the control plane's role. The quiz tests understanding of proxy actions, states, and control plane impact. This helps beginners see how service mesh adds features without modifying app code, unlike library proxies.

Practice

1. What is the main difference between a service mesh and a library-based approach in Kubernetes?

easy

A. Service mesh requires changing app code, library-based works externally

B. Service mesh is for storage, library-based is for networking

C. Service mesh only works with databases, library-based only with APIs

D. Service mesh manages communication outside the app, library-based adds code inside the app

Solution

1. Step 1: Understand service mesh role

   A service mesh manages communication between services outside the app, usually with sidecar proxies.

2. Step 2: Understand library-based approach

   Library-based approach adds communication features inside the app code itself.

3. Final Answer:

   Service mesh manages communication outside the app, library-based adds code inside the app -> Option D

4. Quick Check:

   Service mesh = external, library-based = internal [OK]

Hint: Service mesh is external, library-based is inside app code [OK]

Common Mistakes:

• Confusing which approach requires code changes
• Thinking service mesh only works with databases
• Mixing up external vs internal communication handling

2. Which of the following is a correct statement about implementing a service mesh in Kubernetes?

easy

A. Service mesh uses sidecar proxies injected alongside application pods

B. You must modify each application's source code to use the service mesh

C. Service mesh replaces Kubernetes networking completely

D. Service mesh only works with monolithic applications

Solution

1. Step 1: Recall service mesh architecture

   Service mesh typically uses sidecar proxies injected into pods to handle communication externally.

2. Step 2: Evaluate other options

   Modifying app code is not required; it does not replace Kubernetes networking; it works with microservices too.

3. Final Answer:

   Service mesh uses sidecar proxies injected alongside application pods -> Option A

4. Quick Check:

   Sidecar proxies = service mesh [OK]

Hint: Sidecar proxies run alongside apps in service mesh [OK]

Common Mistakes:

• Thinking app code must be changed for service mesh
• Believing service mesh replaces Kubernetes networking
• Assuming service mesh only supports monoliths

3. Given a Kubernetes app using a library-based approach for service communication, what is the expected output if the app code does not include the library?

medium

A. The app will fail to communicate with other services

B. The app will automatically use a service mesh fallback

C. The app will communicate normally without any issues

D. The app will crash immediately on startup

Solution

1. Step 1: Understand library-based approach dependency

   Library-based approach requires the app code to include the communication library to work properly.

2. Step 2: Predict behavior without library

   If the library is missing, the app cannot handle communication as expected and will fail to connect to other services.

3. Final Answer:

   The app will fail to communicate with other services -> Option A

4. Quick Check:

   Missing library = communication failure [OK]

Hint: Library missing means communication fails [OK]

Common Mistakes:

• Assuming app works without library in library-based approach
• Thinking service mesh auto-fallback happens
• Confusing app crash with communication failure

4. You deployed a service mesh but notice your app is not routing traffic correctly. Which is the most likely cause?

medium

A. The app code lacks the required communication library

B. Sidecar proxy injection failed or is missing

C. The Kubernetes cluster is down

D. The app is using an unsupported programming language

Solution

1. Step 1: Identify service mesh traffic handling

   Service mesh relies on sidecar proxies injected into pods to route traffic correctly.

2. Step 2: Analyze common deployment issues

   If traffic is not routing, a common cause is sidecar proxy injection failure or absence.

3. Final Answer:

   Sidecar proxy injection failed or is missing -> Option B

4. Quick Check:

   Missing sidecar = routing issues [OK]

Hint: Check sidecar proxy injection for routing issues [OK]

Common Mistakes:

• Blaming app code library in service mesh setup
• Assuming cluster is down without checking
• Thinking language support affects routing directly

5. You want to add observability and security features to your Kubernetes microservices without changing app code. Which approach is best and why?

hard

A. Rewrite apps to include custom communication logic

B. Use a library-based approach to add features inside each app

C. Use a service mesh to manage features externally with sidecars

D. Disable all communication features for simplicity

Solution

1. Step 1: Identify requirement to avoid app code changes

   The question states no changes to app code are desired.

2. Step 2: Match approach to requirement

   Service mesh manages communication externally using sidecars, so it adds features without touching app code.

3. Step 3: Evaluate other options

   Library-based requires code changes; rewriting apps is costly; disabling features is not helpful.

4. Final Answer:

   Use a service mesh to manage features externally with sidecars -> Option C

5. Quick Check:

   No code change = service mesh best [OK]

Hint: No code change? Choose service mesh [OK]

Common Mistakes:

• Choosing library-based despite no code change allowed
• Thinking rewriting apps is easier
• Ignoring observability and security needs