Managed Instance Group (MIG)

 Think of a Managed Instance Group (MIG) as a Kubernetes ReplicaSet, but for VMs.

As a backend developer, imagine you need 10 identical application servers running your Spring Boot application.

Instead of manually creating and managing 10 VMs, you:

  1. Define a blueprint (Instance Template)
  2. Tell Google Cloud to maintain 10 copies
  3. Google automatically creates, heals, scales, and updates them

Core Components

1. Instance Template = Blueprint

Contains VM configuration:

  • Machine type
  • OS image
  • Startup scripts
  • Metadata
  • Network settings

Example:

Template:
- Ubuntu
- 4 vCPU
- 16 GB RAM
- Install Java

- Deploy Spring Boot app

This template acts like a Docker image for VMs.

2. Managed Instance Group

Suppose: Desired instances = 3

Google creates:
VM-1
VM-2
VM-3

All from the same template.
MIG
 ├── VM-1
 ├── VM-2
 └── VM-3

Self-Healing Feature

If one VM crashes:

VM-2 dies

MIG notices:
Current = 2
Desired = 3
Automatically creates:
VM-2 (new)

using the same template.

This is called auto-healing.

Auto Scaling

Traffic increases:

100 requests/sec

Need only: 1000 requests/sec

MIG can automatically scale:
3 → 10 VMs

based on:

  • CPU usage
  • Load Balancer traffic
  • Custom metrics
  • Monitoring metrics

When traffic decreases: 10 → 3 VMs


Rolling Updates

Suppose version v1 is running:

Spring Boot v1

Now deploy: Spring Boot v2

Create a new template and update MIG.

Google replaces instances gradually:


Old VM -> New VM
Old VM -> New VM

Old VM -> New VM

No downtime.

This is called a rolling update.


Load Balancer Integration

Without MIG:


Users ---> Single VM

Problem:
VM fails => App unavailable

With MIG:
            VM1
Users -> LB -> VM2
            VM3
            VM4

Load balancer distributes requests across all instances.

Zonal vs Regional MIG

Zonal MIG

Instances in one zone only.


us-central1-a
VM1
VM2

VM3

If the whole zone fails:
Application unavailable

Regional MIG (Recommended)

Instances spread across zones.


us-central1-a
   VM1
   VM2
us-central1-b
   VM3

   VM4

If Zone A fails: 

VM1 ❌
VM2 ❌

Zone B still serves traffic:
VM3 
VM4 

Higher availability.

Google generally recommends Regional MIGs.


MIG Creation Flow

Step 1

Create Instance Template

Blueprint of VM

Step 2

Create Managed Instance Group

Desired Size = N

Step 3

Choose Region/Zone

Regional or Zonal

Step 4

Configure Autoscaling

CPU > 70%

Scale out

Step 5

Configure Health Check

GET /health

Step 6

Attach Load Balancer (optional)

Traffic distributed

Comments

Popular posts from this blog

Async/await

Valid Parentheses

kafka