I Tried AWS Then Azure GCP Is the One I Kept

Introduction

From 2010 to 2015 I was deep in AWS architecture. From 2015 to 2018, Azure. Both are capable platforms — I built real production systems on each. But in 2018, building out infrastructure I was personally responsible for instead of following someone else's existing setup, I tried GCP for the first time. It's the one I kept using by choice ever since.

When cloud complexity starts slowing delivery, cloud design support shows how Taliferro turns cloud architecture into working execution, and the execution model keeps the work tied to outcomes instead of activity.

The difference isn't that GCP is objectively "better" than AWS or Azure — all three run serious production workloads at massive scale. It's that GCP's defaults matched how I actually wanted to build: fewer services to wire together for a working setup, and a console that doesn't require memorizing a separate vocabulary for every product.

What actually made the difference

• Fewer moving parts to get started. A working environment doesn't require standing up a VM and a container orchestrator before writing a line of application code — several services run directly, without provisioning infrastructure first.
• One consistent console. Compute, storage, and data services share the same interface conventions, so switching between them doesn't mean relearning a different product's mental model each time.

Straightforward by default

GCP is designed so you can start with one or two services and add more as the system actually needs them, instead of provisioning for a scale you don't have yet. That matters more than it sounds — over-provisioning early is one of the most common ways cloud costs quietly balloon before a system has any real traffic to justify it.

Easy to get started

A new project takes under a minute to create. Spinning up a VM with a persistent disk, or a container you can run kubectl commands against, happens directly in the console — no separate provisioning step first. The three services that come up most in real architecture work:

• BigQuery — a data warehouse for running SQL queries against very large datasets without managing the underlying servers yourself.
• Google Kubernetes Engine (GKE) — a managed Kubernetes cluster with monitoring and diagnostics built in, so you're not also running the orchestration layer yourself.
• Cloud Storage — object storage that plugs directly into GKE, App Engine, and Firebase Hosting without extra integration work.

BigQuery

BigQuery is a fully managed, pay-as-you-go data warehouse built for datasets too large to comfortably query in a conventional database. Run SQL against it directly, connect it to visualization tools, or use it as a shared storage layer other services and third-party tools read from. The part that matters operationally: you're not sizing or patching the servers underneath it — that's the actual "managed" in "managed data warehouse."

Google Kubernetes Engine

GKE is a managed Kubernetes environment — the equivalent of AWS's EKS or Azure's AKS, if you've used either. Deploy an application and it provisions every component that application needs, including load balancers and storage volumes, automatically. Preemptible instances let you allocate lower-cost capacity for workloads that can tolerate being interrupted, which is a real cost lever for anything batch-oriented that doesn't need to run uninterrupted.

Cloud Storage

This is the one I reach for most. Object storage holds arbitrary data as objects — think a database table where each row can be a file. File storage organizes things into folders the way a local filesystem does. Both handle documents, video, and images, and both are accessible from anywhere without managing a file server.

Why this adds up to a real advantage

Individually, none of these services is unique to GCP — every major cloud provider offers a data warehouse, a managed Kubernetes service, and object storage. What's different is how little glue code it takes to get them working together, and how much less GCP costs at comparable usage than AWS or Azure for the workloads I've actually run on all three. For a small team without a dedicated platform engineer, that gap in setup time is often worth more than a feature comparison chart.

Conclusion

GCP isn't the right choice for every team — plenty of organizations have good reasons to standardize on AWS or Azure, especially if that's where their existing skills and integrations already live. But for teams building from scratch who want fewer services to wire together and a lower bill at the end of the month, it's earned its place as Taliferro's default recommendation for new cloud architecture.

Tyrone Showers