GCP
Google's cloud — strongest in data, ML, and Kubernetes.
GCP's real differentiation over AWS is in the data and ML layer: BigQuery's serverless execution model, Vertex AI's training and serving infrastructure, and GKE's Autopilot mode are all meaningfully ahead of their AWS equivalents. The tradeoff is that GCP's IAM model — with its project/folder/org hierarchy, service account topology, and workload identity federation — takes longer to get right than AWS IAM.
I reach for GCP when the workload fits the ecosystem: apps graduating out of Firebase, pipelines that need BigQuery or Dataflow, or Kubernetes workloads where GKE's reliability matters. The IAM and networking setup is the part that bites people — GCP separates VPC networks from projects, uses shared VPCs across organizational units, and has quota and API enablement nuances that don't exist in AWS. I've worked through those specifics enough to have a repeatable approach: service account topology designed around least privilege from the start, VPC shared at the right org level, budget alerts and committed use discounts configured before anything hits production.
GCP Project Setup
I structure projects under a folder hierarchy that mirrors environment and team boundaries, assign IAM roles at the folder level where they should be inherited and at the project level where they shouldn't, and design service accounts with one-purpose identities rather than catch-all accounts. VPC design follows a shared VPC model with host/service project separation so network policy doesn't get replicated across every project.
GKE & Cloud Run Deployments
The GKE vs. Cloud Run decision comes down to whether the workload needs per-request isolation with no idle cost (Cloud Run) or stateful networking, persistent volumes, and cluster-level scheduling control (GKE). For GKE I configure Autopilot mode by default, set resource requests before anything ships, wire Workload Identity so pods never use a node service account, and set up cluster autoscaler limits and budget alerts on day one.
Data Platform Design
BigQuery schema design starts from partition and clustering keys — time-partitioned on the ingestion or event timestamp, clustered on the fields that appear in WHERE filters most often. For streaming ingestion I use Pub/Sub into Dataflow when I need transformation logic mid-stream; for batch loads or event replay, I go directly to BigQuery Storage Write API. Dataflow adds operational overhead that isn't worth it unless there's actual enrichment or windowed aggregation happening in transit.
AI/ML Product Features
Vertex AI for model training and serving, with Cloud Storage as the artifact and dataset store, Pub/Sub feeding prediction requests, and Cloud Run handling the serving endpoint. The pipeline is event-driven: a message triggers preprocessing, a Vertex job runs inference, and the result is written back to Firestore or BigQuery depending on whether it needs to be queried or just read by key.
Firebase to GCP Graduation
Firebase apps that have outgrown Firestore's query model or need relational integrity move to Cloud SQL or BigQuery on the same GCP billing account. Auth stays on Firebase Auth with the same token contracts — no re-login required. The migration happens incrementally: new data models land in Cloud SQL while existing Firestore collections drain over time.
Analytics-Heavy SaaS
BigQuery's serverless execution model handles ad-hoc queries over large datasets without cluster sizing or index management. Partitioned tables over time-series data keep scan costs predictable, and connected Looker Studio or custom dashboards query directly without an intermediate analytics layer.
Let's talk GCP.
No pitch. Just a technical conversation about the problem you're working on.