GCP Básico: Servicios Core para Desarrolladores

Overview

Google Cloud Platform (GCP) es conocido por su liderazgo en data analytics, AI/ML y Kubernetes. Construido sobre la misma infraestructura que potencia Google Search y YouTube, GCP ofrece a desarrolladores herramientas poderosas para compute, storage, bases de datos y big data. A continuación: los servicios core que necesitas para construir y desplegar aplicaciones en GCP.

When to Use

• For alternatives, see AWS Basics — Core Services for Developers.

• Necesitas servicios de data analytics y AI/ML líderes

• Estás construyendo aplicaciones containerizadas o serverless

• Quieres integración profunda con herramientas open-source (Kubernetes, TensorFlow, Apache Beam)

• Tus workloads se benefician de la red global de Google y su modelo de pricing

Compute: GCE, GKE y Cloud Run

Compute Engine (GCE)

Virtual machines con sizing flexible y pricing (descuentos por uso sostenido, committed use discounts).

# Crear una instancia VM
gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --machine-type=e2-medium \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud \
  --boot-disk-size=20GB

Familia de Máquina	Caso de Uso
E2	Propósito general optimizado en costo
N2/N2D	Balance entre rendimiento y costo
C2/C2D	Workloads intensivos en compute
M1/M2	Intensivos en memoria (ultramem)

Google Kubernetes Engine (GKE)

Kubernetes gestionado con modos autopilot y standard.

# Crear un cluster GKE
gcloud container clusters create my-cluster \
  --zone=us-central1-a \
  --num-nodes=3 \
  --enable-autoscaling \
  --min-nodes=1 \
  --max-nodes=10

# Desplegar una aplicación
kubectl create deployment hello-app --image=gcr.io/project/hello-app:v1
kubectl expose deployment hello-app --type=LoadBalancer --port=80

Cloud Run

Containers serverless: despliega cualquier aplicación containerizada sin gestionar servidores.

# Desplegar un container a Cloud Run
gcloud run deploy hello-service \
  --image=gcr.io/project/hello-app:v1 \
  --platform=managed \
  --region=us-central1 \
  --allow-unauthenticated

Cloud Run escala automáticamente a cero y maneja HTTPS termination.

Storage: Cloud Storage y Persistent Disks

Cloud Storage

Storage de objetos unificado con caching global de edge.

# Crear un bucket
gsutil mb -l us-central1 gs://my-app-bucket

# Subir un archivo
gsutil cp app.zip gs://my-app-bucket/builds/

# Hacer público (con precaución)
gsutil iam ch allUsers:objectViewer gs://my-app-bucket

Clase	Caso de Uso	Almacenamiento Mínimo
Standard	Acceso frecuente	Ninguno
Nearline	Acceso mensual	30 días
Coldline	Acceso trimestral	90 días
Archive	Acceso anual	365 días

Persistent Disks

Block storage para Compute Engine y GKE.

# Crear y adjuntar un disco
gcloud compute disks create my-disk --size=100GB --type=pd-ssd --zone=us-central1-a
gcloud compute instances attach-disk my-vm --disk=my-disk --zone=us-central1-a

Tipo de Disco	IOPS	Throughput	Caso de Uso
pd-standard	500	120 MB/s	Boot disks, bajo I/O
pd-balanced	15,000	240 MB/s	Propósito general
pd-ssd	30,000	480 MB/s	Bases de datos, alto I/O
pd-extreme	120,000	2,200 MB/s	SAP, HPC

Bases de Datos: Cloud SQL, Firestore y BigQuery

Cloud SQL

PostgreSQL, MySQL y SQL Server gestionados con backups automatizados y réplicas.

# Crear una instancia PostgreSQL
gcloud sql instances create mydb \
  --database-version=POSTGRES_15 \
  --tier=db-f1-micro \
  --region=us-central1 \
  --storage-size=10GB

gcloud sql databases create myapp --instance=mydb

Firestore

Base de datos NoSQL serverless con sync en tiempo real y SDKs mobile.

import { getFirestore, doc, setDoc } from 'firebase/firestore';

const db = getFirestore();
await setDoc(doc(db, 'users', 'user-1'), { name: 'Alice', email: 'alice@example.com' });

BigQuery

Data warehouse serverless para analytics a escala petabyte.

-- Query dataset público
SELECT
  name,
  SUM(number) AS total_births
FROM `bigquery-public-data.usa_names.usa_1910_2013`
WHERE gender = 'F'
GROUP BY name
ORDER BY total_births DESC
LIMIT 10;

Networking: VPC

Global Virtual Private Cloud con routing automático.

┌─────────────────────────────────────────────┐
│              Global VPC                       │
│  ┌─────────────┐    ┌─────────────────────┐ │
│  │  Subnet A   │    │     Subnet B        │ │
│  │  (us-east)  │    │     (europe-west)   │ │
│  │  ┌───────┐  │    │  ┌───────┐ ┌─────┐ │ │
│  │  │  VM   │  │    │  │  VM   │ │SQL  │ │ │
│  │  └───┬───┘  │    │  └───┬───┘ └──┬──┘ │ │
│  │      │      │    │      │        │    │ │
│  │  Cloud Load  │    │   Cloud NAT        │ │
│  │  Balancer    │    │   (egress only)    │ │
│  └──────────────┘    └────────────────────┘ │
└─────────────────────────────────────────────┘

Capacidades clave de networking:

• Cloud Load Balancing: Global, anycast-based load balancing
• Cloud CDN: Content delivery con 140+ edge locations
• Cloud Armor: Protección DDoS y WAF
• Private Service Connect: Acceso seguro a servicios gestionados

Seguridad: IAM y Cloud KMS

Identity and Access Management con políticas basadas en recursos.

bindings:
  - members:
      - serviceAccount:my-app@project.iam.gserviceaccount.com
    role: roles/storage.objectViewer
  - members:
      - serviceAccount:my-app@project.iam.gserviceaccount.com
    role: roles/cloudsql.client

Lo que funciona:

• Usa service accounts, no credenciales de usuario
• Habilita VPC Service Controls para prevención de exfiltración de datos
• Usa Cloud KMS para key management y encryption
• Habilita Cloud Audit Logs para todos los servicios

Errores Comunes

• Usar VPC default sin segmentación. Crea networks custom con subnets por environment
• Sobreaprovisionar Compute Engine. Usa recomendaciones de rightsizing
• Ignorar costos de egress. Transferencia de datos entre regiones es cara
• No usar Cloud NAT para instancias privadas. Instancias privadas necesitan internet outbound para updates
• Guardar secrets en variables de entorno. Usa Secret Manager en su lugar

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts. Compare deployed versions with the declared source of truth before debugging behavior differences.

Temas Avanzados

Escenario: Arquitectura Web en GCP

Sistema: App web escalable, multi-region
Requisitos: 99.95% disponibilidad, auto-scaling, DR

Arquitectura:
  Cloud Load Balancing -> Cloud Run (multi-region)
    Region 1: us-central1
    Region 2: europe-west1

  Cloud Run -> Cloud SQL (regional HA)
  Cloud Run -> Firestore (multi-region)
  Cloud Run -> Memorystore Redis
  Cloud Run -> Cloud Storage (assets)

Servicios clave:
  | Capa | Servicio | Configuracion |
  |------|----------|--------------|
  | DNS/Routing | Cloud Load Balancing | Global, HTTP(S) |
  | Compute | Cloud Run | 2 vCPU / 4GB, min 2 max 20 |
  | DB | Cloud SQL PostgreSQL | db-custom-4-15360, HA |
  | NoSQL | Firestore | multi-region nam-eur |
  | Cache | Memorystore Redis | Standard 1GB |
  | Storage | Cloud Storage | Standard + Nearline lifecycle |
  | Monitoring | Cloud Monitoring + Cloud Trace | |
  | Secrets | Secret Manager | |
  | CDN | Cloud CDN | Edge caches global |

Auto-scaling (Cloud Run):
  - Concurrencia: 80 requests por instancia
  - Min instances: 2 (warm), Max: 20
  - CPU > 70% -> scale out
  - Scale to zero en dev (ahorro de costos)

Disaster Recovery:
  | Componente | RPO | RTO | Estrategia |
  |------------|-----|-----|------------|
  | Cloud SQL | < 1min | < 1min | Regional HA (sync replica) |
  | Firestore | 0 | 0 | Multi-region |
  | Cloud Storage | 0 | 0 | Cross-region replication |
  | Cloud Run | 0 | < 30s | Multi-region LB failover |
  | Memorystore | < 1min | < 5min | Failover a replica |

Costos estimados (mensual):
  | Servicio | Costo |
  |----------|-------|
  | Cloud Run (8 instancias) | $800 |
  | Cloud SQL (4 vCPU HA) | $1,200 |
  | Firestore (1M reads/writes) | $200 |
  | Memorystore (1GB) | $150 |
  | Cloud Storage (1TB) | $25 |
  | Load Balancing + CDN | $200 |
  | Secret Manager | $30 |
  | Total | ~$2,600/mes |

Lecciones:
  - Cloud Run escala a cero: ideal para cargas variables
  - Cloud SQL HA da RPO < 1min con replica sincrona
  - Firestore multi-region elimina DR para NoSQL
  - Cloud CDN + Load Balancing es global y serverless
  - Secret Manager integra con Cloud Run via service account

Como elijo entre Cloud Run y GKE?

Usa Cloud Run para servicios stateless simples que no necesitan Kubernetes. Es serverless, escala a cero y cobra por uso. Usa GKE cuando necesitas control total: service mesh, Helm, operadores, workloads stateful, o multiples servicios con networking complejo. Cloud Run es mas simple y barato; GKE es mas flexible. Empieza con Cloud Run y migra a GKE si lo necesitas.

Errores Comunes en Producción

• Tratar la guía como un checklist para completar una vez en lugar de una práctica por evolucionar.
• Adoptar cada recomendación de golpe en lugar de comenzar con un cambio medido.
• Saltar la evaluación de madurez e imponer prácticas avanzadas a un equipo no preparado.
• No actualizar runbooks y expectativas de guardia al introducir nuevas prácticas.
• Ignorar datos reales de incidentes al priorizar qué partes de la guía aplicar primero.
• No asignar un responsable que revise decisiones trimestralmente.
• Copiar ejemplos sin adaptarlos a las herramientas y restricciones reales del equipo.
• Olvidar medir resultados antes de agregar la siguiente mejora.