The System That Refused to Live in One Cloud

Because some projects don’t end when they work — they begin when they do.

There’s a point in every ambitious project when curiosity stops feeling like excitement and starts feeling like obsession.
For me, that moment arrived somewhere between 2 A.M. and another failed IAM binding.

The task on paper was simple: build a cloud-based service using three services.
But simplicity doesn’t survive in the hands of an overthinker with GitHub Actions access and a tendency to chase perfection.

That’s how a university project became a fully automated, multi-cloud MLOps system — one that trains models on GCP, deploys APIs on AWS Lambda and Azure Web Apps, and ties the chaos together with a global load balancer that has seen more redeploys than I’ve had sleep.

It started as coursework.
It ended as a system that refused to live in one cloud — because, maybe, I refused to live inside limits too.

By 2025, “multi-cloud” stopped being a buzzword and quietly became the backbone of global AI infrastructure.
Each provider has a personality:

• GCP — structured, data-native, opinionated about governance.

• AWS — ruthless about precision and cost efficiency.

• Azure — the creative pragmatist, excellent at doing more with less.

So when people ask, “Why not just pick one?”, I ask back,

“Why should reliability have a single region — or a single ideology?”

The modern ML pipeline doesn’t live in isolation.
Data has gravity, compute has cost, and identity has boundaries.
The moment you understand that, you stop being a developer — you start thinking like an architect.

When I built multi-cloud-mlops, I didn’t want to create a submission — I wanted to create an ecosystem that learns to live on its own.

Here’s what that meant in practice:

• Data → GCP BigQuery and Dataform handled transformations declaratively through SQLX.

• Training → Vertex AI and Cloud Build orchestrated continuous retraining triggered from GitHub Actions.

• Deployment → Cloud Run, AWS Lambda and Azure Web Apps handled inference, unified via GCP’s Load Balancer.

• Automation → GitHub Actions served as a neutral control plane chaining workflows: train → package → deploy → monitor.

• Security → Workload Identity Federation (WIF) replaced every static credential. No secrets — just temporary trust tokens.

• Observability → Centralized logging streamed via Firehose (AWS) and EventHub (Azure) into Pub/Sub (GCP), analyzed in BigQuery.

Each layer lived in its own microservice branch:

This wasn’t version control — it was choreography.
Each commit, pull request, and merge acted like a heartbeat, keeping the entire ecosystem alive.

Before automation came trust.

In a single cloud, IAM is a checklist.
In multi-cloud, it’s a negotiation.

The day AWS Lambda tried to publish logs to GCP Pub/Sub, I realized something deeper:
every API call is a handshake between identities.

That realization led me to Workload Identity Federation (WIF) — Google Cloud’s method to let GitHub Actions, AWS, and Azure assume temporary identities without credentials.

It was more than security; it was philosophy.

No long-lived JSON keys.
No environment secrets.
Just ephemeral trust that expires on time — like digital honesty.

That’s when it clicked:

In the cloud, identity isn’t a credential — it’s currency.

By the time the architecture stabilized, the system didn’t just run — it evolved.
A single commit could retrain a model, package it as a Docker image, deploy it to three clouds, route traffic globally, and start logging performance metrics.

All without human intervention.

Measured performance looked like this:

| Metric                        | Observation                                 |
| ----------------------------- | ------------------------------------------- |
|   Uptime                      | 99.93% across ~1,400 API requests           |
|   Mean Recovery Time (MTTR)   | ~1 minute, 7 seconds                        |
|   Retrain-to-Prod Pipeline    | 4–7 minutes per cycle                       |
|   Cost                        | ₹4,634 (GCP) · $0.41 (AWS) · ₹1,119 (Azure) |

For me, these weren’t DevOps metrics — they were emotional diagnostics.
Proof that chaos could be automated, that curiosity could become architecture.

This project didn’t start with confidence. It started with fear — fear that my résumé wasn’t impressive enough, that I wasn’t building “real” systems.
So I overcompensated by building a system that did everything.

And somewhere between debugging IAM roles and merging feat/vertex-ai-pipeline, I realized something:

Architecture is the therapy of overthinkers.

Every pipeline I automated was a metaphor for letting go.
Every redeploy was a lesson in trust.
Every log stream was a mirror of my own need to observe before I break again.

Multi-cloud wasn’t a technical decision — it was emotional infrastructure.

In 2025, multi-cloud is no longer just about enterprise resilience; it’s about personal autonomy.
As creators, students, and engineers, we live in ecosystems that evolve faster than we can commit.
We can’t afford to build brittle systems — not in the cloud, and not in ourselves.

Multi-cloud matters because it embodies a truth I wish someone had told me sooner:

Freedom in engineering isn’t about avoiding failure — it’s about designing for recovery.

If you’ve ever built something just to prove to yourself that you could — welcome, you’re in the right place.
Subscribe to The Multi-Cloud Diaries and let’s explore the systems we build — and the ones that build us back.

Issue #2 — “Killing Secrets: My First Encounter with Workload Identity Federation”
How deleting one JSON key changed everything I thought I knew about trust, security, and control.