Service mesh concept in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a service mesh component that manages communication between microservices.

Microservices

service_mesh = [1]('linker')

Drag options to blanks, or click blank then click option'

AProxy

BGateway

CLoadBalancer

DSidecar

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing 'Proxy' alone without the sidecar pattern.

Confusing 'Gateway' with internal service communication.

Using 'LoadBalancer' which is for traffic distribution, not mesh.

The Sidecar pattern is used in service mesh to manage communication by running alongside each microservice.

2fill in blank

medium

Complete the code to enable secure communication between services in a service mesh.

Microservices

service_mesh.enable_tls([1]=True)

Drag options to blanks, or click blank then click option'

Aencryption

Bmutual_authentication

Cmutual_tls

Dinsecure

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'encryption' alone without mutual verification.

Confusing 'mutual_authentication' which is not a direct parameter.

Setting 'insecure' to True disables security.

Mutual TLS (mTLS) is used in service mesh to secure communication by authenticating both client and server.

3fill in blank

hard

Fix the error in the code to correctly configure traffic routing in a service mesh.

Microservices

service_mesh.route_traffic(source='frontend', destination=[1])

Drag options to blanks, or click blank then click option'

Abackend-service

Bfrontend-service

Cdatabase

Dcache

Attempts:

3 left

💡 Hint

Common Mistakes

Routing traffic back to frontend causing loops.

Routing to database directly instead of backend service.

Routing to cache which is not the main service endpoint.

The destination should be the backend-service to route traffic from frontend to backend correctly.

4fill in blank

hard

Fill both blanks to create a policy that limits requests and retries in a service mesh.

Microservices

policy = [1](max_requests=100, retry=[2])

Drag options to blanks, or click blank then click option'

ARateLimiter

B3

C5

DRetryPolicy

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'RetryPolicy' for rate limiting.

Setting retry count too high or as a string.

Confusing max_requests with retry count.

The RateLimiter controls request limits, and 3 retries is a common retry count.

5fill in blank

hard

Fill all three blanks to define a service mesh configuration that includes observability and fault injection.

Microservices

config = {
  '[1]': True,
  'fault_injection': {'delay': [2], 'percentage': [3]
}

Drag options to blanks, or click blank then click option'

Aobservability

B'100ms'

C10

Dlogging

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'logging' instead of observability.

Setting delay without units or as a number only.

Confusing percentage with delay value.

Observability enables monitoring, 100ms delay simulates latency, and 10% fault injection rate tests resilience.

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