Multi-Cloud Microservices & DevOps Automation

Category: Multi-Cloud · DevOps · Side ProjectStack: Terraform · AWS · GCP · GKE · Kubernetes · GitHub Actions · FastAPI · Django · Vertex AI

Background

This was a self-initiated side project built before an interview. The explicit goal: prove the ability to bring up an unfamiliar cloud platform (GCP) from scratch in a short time — and work through real cross-cloud integration problems.

My previous role was primarily on AWS using AWS CDK. While I was comfortable with AWS, CDK locks you into the AWS ecosystem. This time I deliberately chose Terraform as the IaC tool. Its HCL syntax supports multi-cloud management — the same codebase can provision both AWS and GCP resources.

Architecture

The system consists of a Vue.js frontend, FastAPI backend, and Django auth service, deployed across AWS and GCP with Kubernetes (GKE) for container orchestration.

Real Problems Solved

Problem 1: GCP Deployment via CI/CD

The issue: My initial plan was to use GitHub Actions for the entire CI/CD pipeline. But I got stuck for a long time trying to automatically deploy to GCP.

The root cause: GCP's VPC network and GKE permission model are very strict. GitHub Actions runners are external — they get blocked by the firewall, and granting them deployment access requires a highly privileged Service Account key with serious leak risk.

Solution: Decouple CI and CD

GitHub Actions (CI)
  ├── Run automated tests
  ├── Build Docker image
  └── Push to AWS ECR

GCP Cloud Build (CD)
  ├── Listens for Git merge events
  ├── Runs deployment inside GCP's internal network
  └── Updates services on GKE

Two immediate benefits:

Keyless Authentication: GitHub Actions no longer holds a GCP Service Account key — the credential leak surface is eliminated
Network security: deployment runs inside GCP's internal network, completely bypassing the firewall issue

Problem 2: Cross-Cloud Docker Image Pull

The issue: Docker images are stored in AWS ECR, but they need to run on GCP GKE pods. Cross-cloud identity verification turned out to be non-trivial.

The traditional approach — storing AWS Access Keys as Kubernetes Secrets — has a fundamental flaw: long-lived static credentials are the highest-risk security exposure.

Solution: Workload Identity Federation

I implemented Workload Identity Federation between GCP and AWS:

A GKE pod obtains its GCP Service Account identity via Workload Identity
Through Federation, it exchanges this for a short-lived AWS Token from AWS STS
The short-lived token authenticates against AWS ECR to pull the image

GKE Pod → GCP Workload Identity → AWS STS (Federation) → Short-lived Token → AWS ECR

The token expires automatically. Even if intercepted, it's useless within minutes — a fundamentally safer approach than static keys.

Problem 3: Protecting the Vertex AI API Endpoint

The issue: The FastAPI backend calls GCP Vertex AI (Gemini) for translation. A public API endpoint means anyone can call it freely and drain my GCP quota.

Solution: Two-layer protection

Layer 1 — Django Auth A token-based authentication system ensures only requests with valid tokens can reach the Vertex AI call path.

Layer 2 — Strict CORS Frontend and API gateway configured with strict CORS rules:

python

app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://my-authorized-domain.com"],
    allow_methods=["POST"],
)

Only requests from authorized domains are accepted — unauthorized consumption is blocked at the source.

Version Control and Quality Gates

GitHub Branch Protection Rules on main:

Direct push to main is forbidden — Pull Requests only
PRs must pass all GitHub Actions checks before merging
First line of defense preventing untested code from reaching production

Results

GCP brought from zero to running microservices, proving the ability to ramp up on an unfamiliar cloud platform quickly
Three real cross-cloud integration problems solved (CI/CD decoupling, cross-cloud image pull, API protection)
Terraform provides unified multi-cloud IaC — AWS and GCP resources managed in one versioned codebase

Takeaway

The hardest part of cross-cloud integration isn't the technology itself — it's that every cloud has a different security model and network boundary. AWS IAM and GCP Workload Identity have fundamentally different design philosophies. You need to understand each system's identity model before you can design an elegant solution.

Multi-Cloud Microservices & DevOps Automation ​

Background ​

Architecture ​

Real Problems Solved ​

Problem 1: GCP Deployment via CI/CD ​

Problem 2: Cross-Cloud Docker Image Pull ​

Problem 3: Protecting the Vertex AI API Endpoint ​

Version Control and Quality Gates ​

Results ​

Takeaway ​