Google Cloud — Getting Started with GCP

Google Cloud Platform (GCP) offers a suite of cloud computing services that run on the same infrastructure Google uses internally. Getting started can feel overwhelming with dozens of services and tools. This guide walks you through the fundamentals — signing up for Free Tier, navigating the Console, and using the gcloud CLI and Cloud Shell to manage resources.

Why GCP? A Pragmatic Choice for Production Workloads

Google Cloud Platform (GCP) isn't just another cloud — it's built on the same infrastructure that powers Google Search, YouTube, and Gmail. For DevOps teams, this means battle-tested networking, industry-leading data analytics (BigQuery), and a Kubernetes service (GKE) that's the gold standard. Unlike AWS or Azure, GCP's network is designed for global scale from day one, with low-latency inter-region connectivity and a single VPC that spans the planet. If you're starting fresh, GCP's simpler IAM model and consistent CLI (gcloud) reduce cognitive load. But don't mistake simplicity for weakness — GCP's per-second billing and sustained-use discounts save money without complex reservations. For a beginner, the learning curve is gentler, but the production patterns are just as rigorous. Start here, and you'll build skills that transfer to any cloud.

#!/bin/bash
# Verify GCP project access and list services
gcloud projects list --format="table(projectId, name, lifecycleState)"
gcloud services list --available --format="table(serviceConfig.name, state)"

Setting Up Your GCP Environment: Project, Billing, and IAM

Every GCP resource lives in a project. Think of a project as a logical container for billing, permissions, and APIs. Start by creating a project with a descriptive name (e.g., 'thecodeforge-prod'). Enable billing — without it, most services won't work. Then, set up IAM: avoid using the owner account for daily operations. Create a service account for automation and assign least-privilege roles like 'roles/compute.admin' or 'roles/storage.objectAdmin'. Use gcloud to manage everything: gcloud projects create, gcloud config set project, and gcloud iam service-accounts create. For local development, authenticate with gcloud auth application-default login. This setup mirrors production patterns where CI/CD pipelines use service accounts, not human credentials.

#!/bin/bash
PROJECT_ID="thecodeforge-prod"
SA_NAME="deploy-sa"

gcloud projects create $PROJECT_ID --name="TheCodeForge Production"
gcloud config set project $PROJECT_ID
gcloud services enable compute.googleapis.com container.googleapis.com

gcloud iam service-accounts create $SA_NAME --display-name="Deployment Service Account"
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/compute.admin"

gcloud iam service-accounts keys create ./${SA_NAME}-key.json \
  --iam-account=$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com

echo "Setup complete. Key saved to ${SA_NAME}-key.json"

Core Compute: Choosing Between Compute Engine and GKE

GCP offers two primary compute paths: Compute Engine (VMs) and Google Kubernetes Engine (GKE). For beginners, Compute Engine is simpler — you get a VM, SSH in, and install your app. But for production, GKE is almost always the better choice. Kubernetes abstracts away the underlying VMs, provides self-healing, and enables rolling updates. GKE adds managed node pools, auto-scaling, and integrated logging. The trade-off: GKE has a steeper learning curve. Start with a single-node GKE cluster using gcloud container clusters create with --num-nodes=1. Deploy a simple nginx pod to validate. Once comfortable, explore node auto-repair and cluster autoscaler. For stateless apps, GKE is the default. For stateful workloads (databases), consider Compute Engine or Cloud SQL.

#!/bin/bash
CLUSTER_NAME="demo-cluster"
ZONE="us-central1-a"

gcloud container clusters create $CLUSTER_NAME \
  --zone=$ZONE \
  --num-nodes=1 \
  --machine-type=e2-micro \
  --release-channel=stable

gcloud container clusters get-credentials $CLUSTER_NAME --zone=$ZONE

kubectl create deployment nginx --image=nginx:1.25
kubectl expose deployment nginx --port=80 --type=LoadBalancer

echo "Cluster ready. Get external IP with: kubectl get svc nginx"

Networking: VPCs, Subnets, and Firewall Rules

GCP's Virtual Private Cloud (VPC) is global — one VPC can span regions. Subnets are regional, and you can create them in multiple regions within the same VPC. This simplifies network design: no need for complex peering or VPNs for inter-region communication. Firewall rules are stateful and apply to VMs via network tags. For production, follow the principle of least privilege: default deny ingress, allow only necessary ports. Use gcloud compute firewall-rules create with target tags. For example, allow HTTP only on VMs tagged 'web'. Also, enable Private Google Access so VMs without external IPs can reach Google APIs. This is critical for security — never give a VM a public IP unless absolutely necessary.

#!/bin/bash
VPC_NAME="prod-vpc"
SUBNET_NAME="prod-subnet-us-central1"

gcloud compute networks create $VPC_NAME --subnet-mode=custom
gcloud compute networks subnets create $SUBNET_NAME \
  --network=$VPC_NAME \
  --region=us-central1 \
  --range=10.0.1.0/24 \
  --enable-private-ip-google-access

gcloud compute firewall-rules create allow-http \
  --network=$VPC_NAME \
  --allow=tcp:80 \
  --target-tags=web \
  --source-ranges=0.0.0.0/0

gcloud compute firewall-rules create allow-ssh \
  --network=$VPC_NAME \
  --allow=tcp:22 \
  --target-tags=ssh \
  --source-ranges=YOUR_IP/32

echo "VPC and firewall rules created."

Storage: Cloud Storage Buckets and Persistent Disks

GCP offers two main storage types for compute: object storage (Cloud Storage) and block storage (Persistent Disks). Cloud Storage is for unstructured data: backups, static assets, logs. Buckets are globally unique, and you can set lifecycle policies to auto-delete or archive old objects. Use gsutil for CLI access. Persistent Disks are for VM or GKE pod storage. They're network-attached and can be resized without downtime. For production, always use SSD persistent disks for boot volumes and standard for data that doesn't need high IOPS. Enable snapshots for backup. A common pattern: store application configs in a bucket, mount as a volume using gcsfuse, and keep stateful data on persistent disks.

#!/bin/bash
BUCKET_NAME="thecodeforge-assets"
DISK_NAME="data-disk"

gsutil mb -l us-central1 gs://$BUCKET_NAME
gsutil lifecycle set lifecycle.json gs://$BUCKET_NAME

gcloud compute disks create $DISK_NAME \
  --size=10GB \
  --type=pd-standard \
  --zone=us-central1-a

gcloud compute instances attach-disk my-instance \
  --disk=$DISK_NAME \
  --zone=us-central1-a

echo "Bucket and disk created."

Databases: Cloud SQL vs. Firestore vs. Bigtable

Choosing the right database is critical. Cloud SQL provides managed MySQL, PostgreSQL, and SQL Server — ideal for traditional relational workloads. It handles backups, replication, and failover. Firestore is a NoSQL document database for real-time apps, with strong consistency and offline support. Bigtable is a wide-column NoSQL database for high-throughput, low-latency workloads (e.g., analytics, IoT). For a typical web app, start with Cloud SQL. Use Firestore if you need real-time sync or serverless. Avoid Bigtable unless you have massive scale (TB+). All three integrate with IAM and VPC. For production, always enable point-in-time recovery and automated backups. Test failover by simulating a zone outage.

#!/bin/bash
INSTANCE_NAME="prod-db"
PASSWORD=$(openssl rand -base64 12)

gcloud sql instances create $INSTANCE_NAME \
  --database-version=POSTGRES_15 \
  --tier=db-custom-1-3840 \
  --region=us-central1 \
  --backup-start-time=02:00 \
  --enable-point-in-time-recovery

gcloud sql users set-password postgres \
  --instance=$INSTANCE_NAME \
  --password=$PASSWORD

echo "Database instance created. Password: $PASSWORD"
echo "Save this password securely."

Monitoring and Logging: Cloud Monitoring and Logging

You can't fix what you can't see. GCP's operations suite (formerly Stackdriver) provides Cloud Monitoring for metrics and alerts, and Cloud Logging for centralized logs. For production, set up uptime checks on your external endpoints, create alerting policies for CPU > 80% or 5xx errors, and use log-based metrics to track custom events. The gcloud logging and gcloud monitoring CLIs let you manage everything programmatically. For GKE, enable Cloud Monitoring and Logging at cluster creation. Use the Ops Agent on Compute Engine VMs for deeper metrics. A common mistake: not setting up budget alerts. Always create a budget alert at 50%, 90%, and 100% of your spend.

#!/bin/bash
ALERT_POLICY_NAME="high-cpu"

gcloud alpha monitoring policies create \
  --display-name="High CPU Usage" \
  --condition-display-name="CPU > 80%" \
  --condition-filter='metric.type="compute.googleapis.com/instance/cpu/utilization" AND resource.type="gce_instance"' \
  --condition-threshold-value=0.8 \
  --condition-threshold-duration=300s \
  --notification-channels="projects/$PROJECT_ID/notificationChannels/CHANNEL_ID"

gcloud logging metrics create \
  --description="Count of 5xx responses" \
  --log-filter='httpRequest.status >= 500' \
  http-5xx-count

echo "Alert policy and log metric created."

CI/CD with Cloud Build and Artifact Registry

Automate your deployments with Cloud Build — GCP's managed CI/CD service. It integrates with Cloud Source Repositories, GitHub, and Bitbucket. Define a cloudbuild.yaml that builds a Docker image, pushes it to Artifact Registry, and deploys to GKE or Cloud Run. Artifact Registry replaces Container Registry and supports Docker, Maven, npm, and more. For production, use kaniko for building containers without Docker daemon (more secure). Add vulnerability scanning to Artifact Registry to catch CVEs before deployment. A typical pipeline: lint, test, build, scan, deploy. Use Cloud Build's built-in substitutions for environment-specific configs.

steps:
- name: 'gcr.io/kaniko-project/executor:latest'
  args:
  - --destination=us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$SHORT_SHA
  - --cache=true
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: 'gcloud'
  args:
  - 'deploy'
  - '--image=us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$SHORT_SHA'
  - '--cluster=prod-cluster'
  - '--region=us-central1'
  - '--namespace=default'
  - '--k8s-deployment=my-app'
images:
- 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$SHORT_SHA'

Infrastructure as Code with Terraform and Deployment Manager

Manual infrastructure is fragile. Use Terraform (preferred) or Deployment Manager to define your GCP resources as code. Terraform's HCL is cloud-agnostic and has a rich provider for GCP. Store state in a Cloud Storage bucket with versioning enabled. Use modules to encapsulate common patterns (e.g., VPC, GKE cluster). For production, enforce policies with Terraform Sentinel or GCP's Organization Policies. Never run terraform apply from a local machine — use a CI/CD pipeline with a service account. A common pitfall: not using prevent_destroy on critical resources like databases. Always plan and review changes before applying.

terraform {
  backend "gcs" {
    bucket = "thecodeforge-tfstate"
    prefix = "prod"
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
}

resource "google_compute_network" "vpc" {
  name                    = "${var.env}-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "subnet" {
  name          = "${var.env}-subnet"
  network       = google_compute_network.vpc.id
  region        = var.region
  ip_cidr_range = var.subnet_cidr
}

variable "project_id" {}
variable "region" { default = "us-central1" }
variable "env" {}
variable "subnet_cidr" {}

output "vpc_name" {
  value = google_compute_network.vpc.name
}

Security Best Practices: IAM, VPC Service Controls, and Beyond

Security in GCP is layered. Start with IAM: use predefined roles, avoid primitive roles (owner/editor/viewer), and grant roles at the resource level when possible. Use VPC Service Controls to prevent data exfiltration from managed services like BigQuery or Cloud Storage. Enable Cloud Armor for WAF protection on HTTP(S) load balancers. Use Secret Manager for API keys and passwords. For compliance, enable Audit Logs and export them to a locked bucket. A common mistake: leaving default service accounts with excessive permissions. Disable them and create custom ones. Also, enable Organization Policies to restrict public IPs, disable service account key creation, and require CMEK for encryption.

#!/bin/bash
ORG_ID="123456789012"

gcloud resource-manager org-policies set-policy \
  --organization=$ORG_ID \
  policy.yaml

# policy.yaml content:
# constraint: constraints/compute.vmExternalIpAccess
# listPolicy:
#   allValues: DENY

Cost Management: Budgets, Quotas, and Sustained Use Discounts

GCP's pricing can be complex but manageable. Use budgets and alerts to avoid surprises. Set up a budget at the project level with alerts at 50%, 90%, and 100%. Use quotas to prevent runaway resource consumption — set CPU, disk, and network quotas per region. Understand sustained use discounts: VMs that run for more than 25% of a month get automatic discounts (up to 30%). Committed use contracts (1 or 3 years) offer deeper discounts for predictable workloads. For GKE, use preemptible VMs for batch jobs. Use the gcloud alpha billing commands to programmatically manage budgets. A common mistake: not cleaning up unused resources (e.g., old disks, static IPs). Use the Recommender to identify idle resources.

#!/bin/bash
ACCOUNT_ID=$(gcloud billing accounts list --format="value(name)" --limit=1)

gcloud alpha billing budgets create \
  --billing-account=$ACCOUNT_ID \
  --display-name="Monthly Budget" \
  --budget-amount=1000 \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0 \
  --notifications-rule-pubsub-topic=projects/$PROJECT_ID/topics/budget-alerts

echo "Budget created."

Next Steps: From Beginner to Production-Ready

You've set up a project, deployed a GKE cluster, configured networking, and automated CI/CD. Now, harden your setup. Implement blue/green deployments with GKE's managed ingress. Add a CDN with Cloud CDN for static assets. Use Cloud Functions for event-driven tasks. Monitor everything with Cloud Monitoring dashboards. Finally, document your architecture — use diagrams and runbooks. The path from beginner to production is iterative. Start small, automate everything, and never stop learning. GCP's documentation is excellent; use it. Join the Google Cloud community. And remember: in production, simplicity beats complexity. A simple, well-monitored system is better than a complex, fragile one.

#!/bin/bash
# Blue-green deployment using GKE and Cloud Load Balancing
kubectl apply -f blue-deployment.yaml
kubectl apply -f green-deployment.yaml
kubectl apply -f service.yaml  # points to blue

# Switch traffic to green
kubectl patch service my-app -p '{"spec":{"selector":{"version":"green"}}}'

echo "Traffic switched to green. Verify before deleting blue."