Blue-green deployment in Microservices - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is blue-green deployment?

Blue-green deployment is a technique where two identical environments (blue and green) are used to deploy new software versions. One environment runs the current version, while the other runs the new version. Traffic switches from blue to green once the new version is ready.

beginner

Why use blue-green deployment in microservices?

It reduces downtime and risk by allowing quick rollback. If the new version has issues, traffic can switch back to the old environment without affecting users.

intermediate

What is a key requirement for blue-green deployment?

Having two identical production environments that can run independently and handle full user traffic.

intermediate

How does traffic switching work in blue-green deployment?

Traffic is routed via a load balancer or DNS switch from the current environment (blue) to the new environment (green) once the new version passes tests.

advanced

What are some challenges of blue-green deployment?

It requires double infrastructure cost, data synchronization between environments, and careful handling of database schema changes.

What does the 'green' environment represent in blue-green deployment?

A The current live version serving users

B The new version of the application ready to receive traffic

C A testing environment not connected to production

D A backup environment for disaster recovery

In blue-green deployment, the green environment hosts the new version before switching traffic.

What is the main benefit of blue-green deployment?

A Allows zero downtime and easy rollback

B Simplifies database migrations

C Reduces infrastructure costs

D Eliminates the need for testing

Blue-green deployment allows switching traffic instantly, minimizing downtime and enabling quick rollback.

Which component typically handles traffic switching in blue-green deployment?

A Load balancer or DNS

B Application code

C Database

D Monitoring tool

Load balancers or DNS are used to route user traffic between blue and green environments.

What is a common challenge when using blue-green deployment?

A No way to test new versions

B Inability to rollback

C Double infrastructure cost

D Users see both versions simultaneously

Maintaining two full environments increases infrastructure costs.

When should traffic be switched from blue to green?

A Immediately after deployment starts

B Only during off-peak hours

C Before deploying the new version

D After the new version passes all tests and is stable

Traffic switches only after verifying the new version is stable to avoid user impact.

Explain the blue-green deployment process and its benefits in microservices.

Think of it like switching between two identical rooms where one is ready before moving in.

What are the main challenges to consider when implementing blue-green deployment?

Consider costs and data consistency issues.

Practice

1. What is the main purpose of blue-green deployment in microservices?

easy

A. To improve database query speed

B. To increase the number of microservices in the system

C. To reduce downtime by switching traffic between two identical environments

D. To simplify the codebase by merging services

Solution

1. Step 1: Understand blue-green deployment concept

   Blue-green deployment uses two identical environments to avoid downtime during updates.

2. Step 2: Identify the main goal

   The main goal is to switch traffic between environments to keep the system available without interruption.

3. Final Answer:

   To reduce downtime by switching traffic between two identical environments -> Option C

4. Quick Check:

   Blue-green deployment = reduce downtime [OK]

Hint: Blue-green means two environments for zero downtime [OK]

Common Mistakes:

• Confusing deployment with scaling
• Thinking it improves database speed
• Assuming it merges microservices

2. Which of the following is the correct sequence in a blue-green deployment?

easy

A. Deploy to green, test, switch traffic from blue to green

B. Deploy to blue, switch traffic, then test on green

C. Switch traffic first, then deploy to blue

D. Deploy to green, switch traffic, then test on blue

Solution

1. Step 1: Recall deployment steps

   In blue-green deployment, new code is deployed to the inactive environment (green).

2. Step 2: Test and switch traffic

   After testing green, traffic is switched from blue (active) to green (new).

3. Final Answer:

   Deploy to green, test, switch traffic from blue to green -> Option A

4. Quick Check:

   Deploy-test-switch = A [OK]

Hint: Deploy to inactive env, test, then switch traffic [OK]

Common Mistakes:

• Switching traffic before testing
• Testing on active environment
• Deploying after switching traffic

3. Consider this simplified code snippet for switching traffic in blue-green deployment:

current_env = "blue"
new_env = "green"
if current_env == "blue":
    current_env = new_env
else:
    current_env = "blue"
print(current_env)

What will be the output?

medium

A. "blue"

B. None

C. SyntaxError

D. "green"

Solution

1. Step 1: Analyze initial variables

   current_env starts as "blue", new_env is "green".

2. Step 2: Evaluate the if condition

   Since current_env == "blue", it sets current_env = new_env, which is "green".

3. Final Answer:

   "green" -> Option D

4. Quick Check:

   Switching from blue to green prints green [OK]

Hint: If current is blue, switch to green [OK]

Common Mistakes:

• Confusing assignment direction
• Expecting original value to print
• Thinking code has syntax error

4. A team uses blue-green deployment but users report downtime during the switch. What is the most likely cause?

medium

A. The old environment was not shut down

B. Traffic was switched before the new environment was fully ready

C. The database was not updated

D. The new environment was tested too long

Solution

1. Step 1: Understand downtime cause in blue-green

   Downtime usually happens if traffic switches before the new environment is ready to serve requests.

2. Step 2: Evaluate options

   Old environment running or database update issues don't cause immediate downtime during switch; testing too long delays deployment but not downtime.

3. Final Answer:

   Traffic was switched before the new environment was fully ready -> Option B

4. Quick Check:

   Premature traffic switch = downtime [OK]

Hint: Switch traffic only after new env is ready [OK]

Common Mistakes:

• Assuming old env causes downtime
• Ignoring readiness checks
• Blaming database updates for switch downtime

5. You manage a critical microservices system using blue-green deployment. After switching traffic to green, you discover a severe bug. What is the best immediate action to minimize downtime?

hard

A. Switch traffic back to blue environment immediately

B. Fix the bug in green environment and keep traffic there

C. Restart both environments simultaneously

D. Deploy a new environment and switch traffic there

Solution

1. Step 1: Understand rollback in blue-green deployment

   Blue-green allows quick rollback by switching traffic back to the previous stable environment (blue).

2. Step 2: Evaluate options for minimizing downtime

   Fixing bug in green delays recovery; restarting both causes downtime; deploying new environment takes time.

3. Final Answer:

   Switch traffic back to blue environment immediately -> Option A

4. Quick Check:

   Rollback by switching traffic = minimize downtime [OK]

Hint: Rollback by switching traffic to old env fast [OK]

Common Mistakes:

• Trying to fix bug before rollback
• Restarting both environments causing downtime
• Deploying new env wastes time