13 - Global and Internal Load Balancing

Welcome to Day 13 of Learn GCP in 30 Days! Yesterday, you learned how Managed Instance Groups (MIGs) create pools of server clones. Today, we give those servers a single front door: GCP Cloud Load Balancing.

The Core Problem: Multiple Server IPs & Overloaded Servers

Yesterday, we created a Managed Instance Group with server clones. But each server clone has its own separate IP address!

Imagine running an online business and telling your customers: "If Server 1 (34.93.10.5) is slow, please manually try typing Server 2 (34.93.10.6) in your browser!"

What Existed Previously:

In traditional setups, without a load balancer, companies had to give users different server IP addresses or manually assign domains to individual servers.

Problems Faced:

• 🤯 Confusing Multiple IPs: Customers cannot memorize or guess which server is free and working.
• ⚖️ Uneven Traffic Load: Server 1 might get flooded with 10,000 visitors and crash, while Server 2 and Server 3 sit completely empty!
• 💥 Dead Links on Server Crash: If Server 1 crashes, every customer visiting Server 1's IP address sees a blank "Connection Failed" screen.

How Present Technology Solves It:

Google Cloud provides Cloud Load Balancing:

1. Single Anycast IP: Gives your entire global application 1 single public IP address (e.g. 34.120.50.10) or domain name (mycoolapp.com).
2. Smooth Traffic Distribution: Sits at the front entrance, receives all incoming customer requests, and forwards them smoothly across your backend servers.
3. Smart Health Check Routing: If Server 1 crashes, the Load Balancer instantly stops sending traffic to Server 1 and redirects all visitors to healthy Server 2!
4. Global Anycast Routing: A visitor in Mumbai gets routed to your Mumbai server pool, while a visitor in London gets routed to Europe—using Google's private subsea network!

Real-World Analogy: The Bank Queue Manager

Imagine walking into a busy Bank:

• 🚪 Frontend IP = 1 Main Front Door: You don't walk directly to a specific teller's desk in the back room. Everyone enters through 1 Main Front Entrance.
• 👮 Queue Manager = Load Balancer: Standing at the door, handing out tickets, and directing each customer to whichever teller counter (Server 1, Server 2, or Server 3) is free.
• 🩺 Health Check = Manager Checking Counters: If Teller 3 goes on a tea break or faints, the Manager stops sending customers to Counter 3 and directs everyone to Counter 1 and 2!

🔑 Everyday Cloud Terms Explained in Plain English

Let me break down essential load balancing terms into clear, simple facts:

1. Load Balancer (The Traffic Manager)

A Load Balancer is a high-speed software traffic manager that sits between internet visitors and your backend servers to distribute incoming requests evenly.

2. Frontend vs. Backend Service (Explained Simply)

Think of a Load Balancer as a system with 2 distinct sides:

• 🌐 Frontend (The Public Internet Side):

  • The Frontend is the Public Outside Door.
  • It has a single public IP address and listens on Port 80 (HTTP).
  • When a customer opens your website on their phone or laptop, their browser connects directly to this Frontend IP address.

• 🏢 Backend / Backend Service (The Server Pool Side):

  • The Backend is the Hidden Pool of Computers behind the scenes.
  • It is the group of Virtual Machines (our Managed Instance Group) that actually store your website files.
  • When the Frontend receives a request from a customer, it hands the request over to the Backend Service, which picks a healthy VM to serve the web page.

🌐 Full-Stack Application Setup: Where Do Load Balancers Fit In?

When building a real-world web application, you create 2 main server layers:

1. Frontend Server: Contains only the visual UI (buttons, layouts, colors) that the user looks for.
2. Backend Server: Contains the actual data (user accounts, payments, database records) that fills in the UI.

When a customer types your website URL, the application handles data in one of 2 ways:

🅰️ Mode 1: Public Backend Mode (Browser Calls API Directly)

1. You type the website URL in your browser.
2. The Frontend Server provides the UI layout to your browser.
3. Your browser directly calls the Public Backend Server to fetch data.
4. Your browser receives the data and displays it inside the UI.

🔒 Security Note: "Public Backend" does not mean anyone can steal data—it is secured so only authorized users (logged-in users) can retrieve data!

🅱️ Mode 2: Private Backend Mode (Server-Side Rendering / SSR)

1. You type the website URL in your browser.
2. The Frontend Server receives your request and calls the Private Backend Server internally inside the network to get data.
3. The Frontend Server fills the data into the UI and sends the complete finished web page to your browser.

🛡️ Privacy Note: Here, the Backend Server has zero public internet access—it stays 100% private inside your VPC network! (That means only the Frontend Server you created can call the Backend).

⚖️ Where Load Balancers Fit In:

As a developer, you build Load Balancers in front of both server layers to distribute incoming traffic across multiple server clones:

• Public External Load Balancer: Built in front of Publicly Available Servers (Frontend UI or Public API) to split millions of internet visitors across multiple servers.
• Private Internal Load Balancer: Built in front of Private Internal Servers (Private API or Database) to split internal data requests across multiple servers inside Google's secure network.

3. Why Do We Need a Health Check? (Traffic Protection)

Without a Health Check, if Server 1 crashes or freezes at 2:00 AM, the Load Balancer would have no idea it is dead! It would keep sending 33% of your website visitors to Server 1, giving those customers a blank "Connection Failed" screen.

How Health Checks Solve It:

1. 💓 Continuous Heartbeat: GCP sends a quiet test message to Port 80 on every server every 5 seconds ("Are you healthy?").
2. 🛑 Instant Rerouting: If Server 1 fails 2 or 3 checks, the Load Balancer marks it Unhealthy and instantly redirects 100% of visitors to healthy Server 2 and 3—with zero downtime for users!
3. 🔄 Automatic Recovery: When Server 1 comes back online and passes health checks again, the Load Balancer automatically resumes sending traffic to it.

4. Global HTTP(S) Load Balancer vs. Internal Load Balancer

Google Cloud offers different load balancer types based on where your traffic flows:

5. Anycast IP (One Global IP for the World)

Normally, an IP address belongs to 1 specific computer building.

GCP's Global Anycast IP is a special Google network technology where 1 single IP address is advertised across Google's 100+ global network locations worldwide!

• When a user in Mumbai opens your site, Google routes them to the nearest Mumbai data center.
• When a user in New York opens the exact same IP, Google routes them to New York—keeping page loads blazing fast!

6. Load Balancer Health Check vs. MIG Health Check

It is easy to confuse these 2 health checks:

• 🩺 MIG Health Check (Autohealing): If a server fails, the MIG deletes and replaces the broken server.
• ⚖️ Load Balancer Health Check (Traffic Rerouting): If a server fails, the Load Balancer stops sending traffic to that server until it becomes healthy again.

🧪 Hands-on Lab Activity: Creating an External HTTP Load Balancer

You can create a Global HTTP Load Balancer in GCP using either the Web Console Website (UI) or Cloud Shell (CLI)!

Step 0: Prerequisite - Create my-mig (If you deleted it yesterday)

Since we cleaned up our resources at the end of Day 12, run this quick command in Cloud Shell to create my-app-template and my-mig (2 server clones) in 1 minute:

# 1. Open Firewall Port 80
gcloud compute firewall-rules create allow-http-web --direction=INGRESS --priority=1000 --action=ALLOW --rules=tcp:80 --target-tags=http-server 2>/dev/null || true

# 2. Create Instance Template
gcloud compute instance-templates create my-app-template \
    --region=asia-south1 \
    --machine-type=e2-micro \
    --tags=http-server \
    --metadata=startup-script='#!/bin/bash
apt-get update
apt-get install -y nginx
echo "<h1>Hello World from Managed Instance Group behind Load Balancer!</h1>" > /var/www/html/index.html' 2>/dev/null || true

# 3. Create Managed Instance Group (MIG) with 2 servers
gcloud compute instance-groups managed create my-mig \
    --zone=asia-south1-a \
    --template=my-app-template \
    --size=2 2>/dev/null || true

Activity 1: Create an HTTP Load Balancer

Method A: Web Console Website (UI Click-by-Click)

1. Log into console.cloud.google.com.
2. Find Load Balancing:
   • Press the / key on your keyboard, type Load balancing, and press Enter.
   • Or click ☰ $\rightarrow$ scroll to Networking (or Network services) $\rightarrow$ click Load balancing.
3. Click Create Load Balancer at the top.
4. Step 1 (Type of load balancer): Select Application Load Balancer (HTTP/S).
5. Step 2 (Public facing or internal): Select Public facing (external).
6. Step 3 (Global or single-region deployment): Select Best for global workloads (Multiple regions with global Anycast IP).
7. Step 4 (Load balancer generation): Select Global external application load balancer.
8. Step 5: Click Create load balancer (or Configure).
9. Name Your Load Balancer:
   • Set Load balancer name: my-web-lb
10. Configure Frontend (Public Internet Door):
    • Click Frontend configuration.
    • Protocol: HTTP | Port: 80 | IP version: IPv4 $\rightarrow$ Click Done.
11. Configure Backend (Server Pool Side):
    • Click Backend configuration $\rightarrow$ Click Backend services & backend buckets $\rightarrow$ Create a backend service.
    • Name: my-backend-service | Protocol: HTTP.
    • Under Backends, select Instance group my-mig.
    • Under Health check, select Create a health check (Name: http-basic-check, Port: 80) $\rightarrow$ Save.
    • Click Create.
12. Click Review and create $\rightarrow$ Click Create!

Method B: Cloud Shell CLI (Command Terminal)

1. Click Activate Cloud Shell (>_) at the top right of your GCP Console.
2. Create an HTTP Health Check:
   bash

   gcloud compute health-checks create http http-basic-check --port=80
   

3. Create Backend Service & Add MIG (my-mig):
   bash

   gcloud compute backend-services create my-backend-service \
       --protocol=HTTP \
       --health-checks=http-basic-check \
       --global
   
   gcloud compute backend-services add-backend my-backend-service \
       --instance-group=my-mig \
       --instance-group-zone=asia-south1-a \
       --global
   

4. Connect Frontend Public IP to Backend Service:
   bash

   gcloud compute url-maps create my-url-map --default-service=my-backend-service
   gcloud compute target-http-proxies create my-http-proxy --url-map=my-url-map
   gcloud compute forwarding-rules create my-http-rule \
       --global \
       --target-http-proxy=my-http-proxy \
       --ports=80
   

Activity 2: Test Traffic Distribution

1. Find the Frontend IP address:
   • Via Console: Go to Load balancing $\rightarrow$ Copy the IP under my-web-lb.
   • Via Cloud Shell: Run gcloud compute forwarding-rules describe my-http-rule --global --format="value(IPAddress)".
2. Open a new tab in your web browser and type http://YOUR_LOAD_BALANCER_IP.
3. Press Enter! The Load Balancer receives your request at the Frontend IP and smoothly routes you to one of your healthy MIG servers in the Backend pool!

🧹 Clean Up Step (Credit Safety Guarantee)

Delete your test Load Balancer, MIG, and Template so your account costs drop back to $0.00:

• Via Web Console UI:
  1. Go to Load balancing $\rightarrow$ Select my-web-lb $\rightarrow$ Click Delete.
  2. Go to Instance groups $\rightarrow$ Select my-mig $\rightarrow$ Click Delete.
  3. Go to Instance templates $\rightarrow$ Select my-app-template $\rightarrow$ Click Delete.
• Via Cloud Shell CLI:
  bash

  gcloud compute forwarding-rules delete my-http-rule --global --quiet
  gcloud compute target-http-proxies delete my-http-proxy --quiet
  gcloud compute url-maps delete my-url-map --quiet
  gcloud compute backend-services delete my-backend-service --global --quiet
  gcloud compute health-checks delete http-basic-check --quiet
  gcloud compute instance-groups managed delete my-mig --zone=asia-south1-a --quiet
  gcloud compute instance-templates delete my-app-template --quiet
  gcloud compute firewall-rules delete allow-http-web --quiet
  

Signal vs. Noise: Key Concepts & Noise Filter

Common Doubts & Interview Traps

Q1: How do Load Balancers protect both Frontend and Backend Application layers?

• Answer: A Public External Load Balancer sits in front of Frontend UI servers to manage public visitors. A Private Internal Load Balancer sits between Frontend UI servers and Backend API servers to split data calls securely inside Google's private network (where only the Frontend server can call the Backend).

Q2: What is the difference between Load Balancer Health Checks and MIG Autohealing Health Checks?

• Answer: Load Balancer health checks reroute traffic away from an unhealthy server. MIG autohealing health checks delete and replace an unhealthy server.

Q3: Why should I put a Load Balancer in front of my Managed Instance Group?

• Answer: Because a MIG creates multiple servers with separate IPs. A Load Balancer gives your entire MIG 1 single public IP address and distributes customer traffic evenly.

Daily Practice Drill & Self-Check

Test your understanding of today's lesson:

// Try answering these:
1. What component acts as the public internet door (IP address & Port 80) of a Load Balancer: Frontend or Backend Service?
2. In Private Backend Mode, who is allowed to call the Private Backend Server: the Public Internet or the Frontend Server?
3. If Server 1 fails a Load Balancer health check, what does the Load Balancer do?

🎉 Awesome job! You have completed Day 13.

You now master GCP Load Balancing, Anycast IPs, Frontend vs Backend Services, Full-Stack setup, and Health Check traffic rerouting! Take a break, let today's concepts sink in, and come back tomorrow fresh!

Tomorrow on Day 14, we will put everything from Week 2 together in our Week 2 Capstone Hands-on Lab: High-Availability Web Cluster!

← 12 - Managed Instance Groups and Autoscaling | Next Topic → 14 - Hands-on Lab - High-Availability Web Cluster