DEV Community

Cover image for Getting Started with Google Cloud Platform (GCP): A Practical Guide for Developers
Kamal Rhrabla
Kamal Rhrabla

Posted on

Getting Started with Google Cloud Platform (GCP): A Practical Guide for Developers

#beginners #cloud #google #tutorial

Google Cloud Platform (GCP) is Google’s suite of cloud services for building, deploying, and operating applications at scale. If you’ve used AWS or Azure, GCP will feel familiar but it also has some “Google-native” strengths like BigQuery, first-class Kubernetes support, and strong data/ML tooling.

This post is a developer-focused introduction: what GCP is great at, the core services you should know, and a simple path to start shipping real projects.

Why use GCP?

GCP is a strong choice if you care about:

  • Managed compute that scales cleanly (especially serverless)
  • Containers + Kubernetes (Google created Kubernetes)
  • Data workloads (analytics, warehousing, streaming)
  • Machine learning tooling (MLOps, training, model hosting)
  • Global infrastructure + networking

It’s also easy to start small (serverless) and grow into more complex architecture only when you need it.

The mental model: how GCP is organized

Before jumping into services, it helps to know the hierarchy:

  • Organization (company/domain; optional for personal projects)
  • Folders (optional grouping)
  • Projects (the main unit for billing, IAM, and resources)
  • Resources (VMs, buckets, databases, etc.)

For most developers, a Project is where everything begins.

Tip: Use separate projects for dev, staging, and prod if you can especially once billing and IAM start to matter.

Core GCP services developers should know

1) Compute (where your code runs)

  • Cloud Run: Run containers without managing servers. Great default for APIs, web apps, and workers.
  • App Engine: PaaS-style deploys (less common in brand-new systems, but still used).
  • Compute Engine: Virtual machines (full control).
  • GKE (Google Kubernetes Engine): Managed Kubernetes for orchestration at scale.

Rule of thumb:

  • If you can containerize it → start with Cloud Run
  • If you need orchestration across many services → consider GKE
  • If you need low-level control → use Compute Engine

2) Storage (files and blobs)

  • Cloud Storage: Object storage for uploads, artifacts, backups, media, static assets.

Good use cases:

  • User uploads (images/video)
  • Build artifacts (zips, containers metadata)
  • Data exports/imports
  • Static website assets behind CDN

3) Databases (store application data)

  • Cloud SQL: Managed PostgreSQL / MySQL / SQL Server.
  • Firestore: NoSQL document database (great for event-driven/mobile/web apps).
  • Spanner: Globally distributed relational DB (powerful, enterprise-grade).

If you’re building a typical web backend, Cloud SQL (Postgres) is a great starting point.

4) Messaging + async workloads

  • Pub/Sub: Event streaming and messaging.
  • Cloud Tasks: Managed task queues (great for background jobs triggered by HTTP).

A common “serverless backbone” looks like:

  • Cloud Run (API) → Pub/Sub (events) → Cloud Run (worker)

5) IAM (permissions)

IAM controls who can do what.

  • Prefer least privilege over broad admin access
  • Use service accounts for apps and automation
  • Avoid giving everyone Owner (it’s convenient and also risky)

IAM feels annoying until it saves you from accidental production changes or surprise bills.

A practical starter architecture (small, modern, scalable)

If you want a “default” GCP stack for a new product:

  • Cloud Run for your API (containerized)
  • Cloud SQL (Postgres) for relational data
  • Cloud Storage for file uploads
  • Secret Manager for secrets (DB passwords, API keys)
  • Cloud Logging + Error Reporting for observability
  • Cloud Build for CI/CD (optional, but very handy)

This setup is production-friendly without forcing you to operate servers.

Getting hands-on: a simple path to ship something

Here’s a practical 30–60 minute plan:

  1. Create a GCP project
  2. Enable billing (many services require it)
  3. Install the Google Cloud SDK (gcloud)
  4. Deploy a small container to Cloud Run
  5. Add Cloud SQL only after your service is deployed and reachable

The key is momentum: deploy something tiny first, then iterate.

Common mistakes (and how to avoid them)

  • Using Owner everywhere → create scoped roles/service accounts.
  • Mixing regions randomly → pick a region near your users and keep services aligned.
  • No budgets/alerts → set a budget alert on day one.
  • Starting with Kubernetes too early → Cloud Run often covers your needs for a long time.

When GCP really shines

GCP is especially strong for:

  • Analytics-heavy products (BigQuery is a standout)
  • Event-driven systems (Pub/Sub + Cloud Run)
  • Kubernetes-based platforms (GKE + ecosystem)
  • ML workflows (Vertex AI + data tooling)

Conclusion

You don’t need to learn all of GCP to be productive. Pick a small core:
Cloud Run + Cloud SQL + Cloud Storage + IAM + Logging, and you can ship real services quickly.

Top comments (0)