Semana 10 · Módulo 10 de 12

Entrega e implementación — CI/CD, infraestructura como código, APIs y herramientas

Verás cómo llega el código a producción en Google Cloud (Cloud Build, Artifact Registry, Cloud Deploy y estrategias de despliegue), cómo se gestiona la infraestructura como código con Terraform, cuándo usar Apigee o API Gateway y qué herramientas programáticas debe recomendar un arquitecto a los equipos. Cubre los apartados 4.1, 5.1, 5.2 y 6.3.

Reparto de la semana

Por qué importa

Las secciones 4.1, 5 y 6.3 suman en torno a un tercio del peso de las secciones 4-6. Las preguntas típicas son de asesoramiento: «El equipo despliega a mano y tiene caídas en cada versión, ¿qué recomiendas?», «Hay que exponer APIs a socios con cuotas y monetización, ¿qué producto?», «Los desarrolladores quieren probar contra Pub/Sub sin coste ni conexión a la nube, ¿qué usan?». Como arquitecto no te piden escribir el pipeline, sino elegir las piezas correctas y justificar el riesgo.

SDLC y DevOps en Google Cloud

El SDLC (Software Development Lifecycle) es el ciclo planificar → codificar → construir → probar → publicar → desplegar → operar → monitorizar. DevOps es la cultura y las prácticas que acortan ese ciclo sin perder estabilidad: equipos responsables de su servicio de principio a fin, automatización, cambios pequeños y frecuentes, y medición.

Google impulsa el programa de investigación DORA (DevOps Research and Assessment), cuyas métricas de entrega de software son la referencia: frecuencia de despliegue, tiempo de entrega de cambios, tasa de cambios fallidos y tiempo de recuperación tras un fallo. Los equipos de alto rendimiento mejoran a la vez velocidad y estabilidad: no son objetivos opuestos.

Mapa de productos de Google Cloud en el ciclo:

flowchart LR
  DEV["Código (Cloud Shell Editor, Cloud Code, Gemini Code Assist)"] --> SCM["Repositorio Git (GitHub, GitLab, Bitbucket, Secure Source Manager)"]
  SCM -->|"trigger"| CB["Cloud Build: pruebas y build"]
  CB -->|"imagen o paquete"| AR["Artifact Registry + Artifact Analysis"]
  AR --> CD["Cloud Deploy: release y promoción"]
  CD --> DEVENV["dev"] --> STG["staging"] --> PROD["prod (canary)"]
  PROD --> OBS["Google Cloud Observability"]

Integración continua con Cloud Build

Cloud Build es el servicio serverless de CI de Google Cloud: ejecuta una serie de pasos (steps), cada uno en un contenedor, sobre tu código fuente. Pagas por minuto de build. Precio orientativo a septiembre de 2026: cada cuenta de facturación tiene 2.500 minutos de build gratis al mes (máquina e2-standard-2 en el pool por defecto) y después unos 0,006 USD/min en esa máquina; consulta cloud.google.com/build/pricing.

El fichero cloudbuild.yaml

steps:
  # 1. Pruebas unitarias
  - name: 'python:3.12-slim'
    entrypoint: 'bash'
    args: ['-c', 'pip install -r requirements.txt && python -m pytest']
  # 2. Construir la imagen
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/app:$SHORT_SHA', '.']
# Imágenes que Cloud Build sube a Artifact Registry al terminar
images:
  - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/app:$SHORT_SHA'
substitutions:
  _REGION: europe-southwest1
  _REPO: apps
options:
  logging: CLOUD_LOGGING_ONLY

Conceptos:

• Builders: imágenes que ejecutan cada paso. Google mantiene los cloud builders (gcr.io/cloud-builders/docker, gcloud, git…) y puedes usar cualquier imagen pública o tuya.
• Sustituciones (substitutions): variables predefinidas ($PROJECT_ID, $BUILD_ID, $SHORT_SHA, $BRANCH_NAME en builds con trigger) y personalizadas, que empiezan por guion bajo (_REGION).
• Secretos: nunca en el YAML. Se leen de Secret Manager con el campo availableSecrets.
• Cuenta de servicio: desde 2024, en proyectos nuevos Cloud Build usa por defecto la cuenta de servicio predeterminada de Compute Engine en lugar de la antigua cuenta heredada de Cloud Build. Buena práctica: una cuenta de servicio dedicada por pipeline con el mínimo privilegio.
• Ejecución manual: gcloud builds submit --region=REGION --config=cloudbuild.yaml sube el directorio actual y lanza el build.

Triggers

Un trigger lanza un build automáticamente ante un evento:

• Push a una rama (típico: main → build y despliegue a dev).
• Push de un tag (típico: v1.2.0 → release).
• Pull request (ejecutar pruebas antes de fusionar).
• También manual, por mensaje de Pub/Sub o por webhook.

Repositorios soportados: GitHub, GitHub Enterprise, GitLab (incluido Enterprise Edition), Bitbucket (Cloud, Server y Data Center) y Secure Source Manager (el repositorio Git gestionado de Google). Cloud Source Repositories ya no está disponible para clientes nuevos desde el 17 de junio de 2024: si una respuesta lo propone para un proyecto nuevo, desconfía.

gcloud builds triggers create github \
  --name=build-main \
  --region=europe-southwest1 \
  --repo-name=mi-app --repo-owner=mi-org \
  --branch-pattern='^main$' \
  --build-config=cloudbuild.yaml \
  --service-account=projects/PROJECT_ID/serviceAccounts/cb-pipeline@PROJECT_ID.iam.gserviceaccount.com

Pools privados

Por defecto los builds se ejecutan en el default pool, gestionado por Google y con acceso solo a Internet público. Un private pool es un conjunto de trabajadores dedicado que:

• Se conecta a tu VPC (o a una Shared VPC) por peering, así el build puede llegar a recursos privados: un Artifactory interno, una base de datos de pruebas, un clúster de GKE privado o sistemas on-premises vía VPN/Interconnect.
• Permite desactivar la IP pública de los trabajadores y usar rangos internos estáticos.
• Es compatible con VPC Service Controls.
• Ofrece muchos más tipos de máquina y más concurrencia.

Artifact Registry

Artifact Registry es el registro gestionado de artefactos: imágenes de contenedor (Docker/OCI) y paquetes de lenguaje y sistema (Maven, npm, Python, Go, Apt, Yum, entre otros). Sustituye a Container Registry, ya retirado.

• Repositorios regionales o multirregionales, con IAM por repositorio (p. ej. roles/artifactregistry.reader para quien despliega, writer para el pipeline).
• Tipos de repositorio: standard (tus artefactos), remote (caché de un registro externo como Docker Hub o PyPI: acelera y protege frente a caídas o límites del origen) y virtual (un único punto de acceso que agrega varios repositorios).
• Artifact Analysis escanea vulnerabilidades en las imágenes; con Binary Authorization (módulo 7) solo se despliegan imágenes firmadas o que cumplen la política.
• Hostname de las imágenes: REGION-docker.pkg.dev/PROYECTO/REPOSITORIO/IMAGEN:TAG.
• Precio orientativo (septiembre de 2026): 0,5 GB de almacenamiento gratis y después unos 0,10 USD/GB-mes; consulta cloud.google.com/artifact-registry/pricing.

Entrega continua con Cloud Deploy

Cloud Deploy es el servicio gestionado de entrega continua hacia GKE, Cloud Run y otros destinos. Separa el qué (el artefacto construido) del cómo (la progresión de entornos). Conceptos:

Ejemplo de clouddeploy.yaml con canary en producción para Cloud Run:

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: app-pipeline
serialPipeline:
  stages:
  - targetId: dev
    profiles: [dev]
  - targetId: prod
    profiles: [prod]
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [10, 50]
          verify: false
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod
requireApproval: true
run:
  location: projects/PROJECT_ID/locations/europe-southwest1

Flujo con gcloud:

gcloud deploy apply --file=clouddeploy.yaml --region=europe-southwest1
gcloud deploy releases create rel-001 --delivery-pipeline=app-pipeline \
  --region=europe-southwest1 --images=app-image=IMAGEN@sha256:DIGEST
gcloud deploy releases promote --release=rel-001 --delivery-pipeline=app-pipeline \
  --region=europe-southwest1 --to-target=prod

Puntos clave:

• La release se crea con la imagen referenciada por digest (@sha256:...): lo que se prueba en dev es exactamente lo que llega a prod.
• Rollback con un clic o con gcloud deploy targets rollback: vuelve a desplegar la release anterior que funcionaba.
• Canary automatizado: en Cloud Run, Cloud Deploy reparte el tráfico entre la revisión estable y la nueva según los porcentajes (el 100 % es la fase final stable). En GKE puede hacerlo con Service o con Gateway API.
• Verify, predeploy y postdeploy jobs: contenedores que se ejecutan en el rollout para pruebas de humo o tareas previas.
• Automatizaciones: promover o avanzar fases automáticamente cuando se cumplen condiciones.
• Pipeline típico integrado: Cloud Build construye, prueba y sube la imagen y, en el último paso, ejecuta gcloud deploy releases create. A partir de ahí manda Cloud Deploy.
• Precio orientativo (septiembre de 2026): el primer delivery pipeline activo con varios targets por cuenta de facturación es gratis y cada adicional cuesta 5 USD al mes; consulta cloud.google.com/deploy/pricing.

Estrategias de despliegue (apartado 6.3)

Ejemplos de Cloud Run: gcloud run deploy SERVICE --image IMAGE --no-traffic --tag candidata despliega una revisión sin tráfico (accesible por una URL con tag para probarla) y gcloud run services update-traffic SERVICE --to-revisions REVISION=10 le da el 10 %.

Infraestructura como código

IaC significa describir la infraestructura en ficheros versionados y aplicarlos con una herramienta, en lugar de hacer clic en la consola. Beneficios: repetibilidad (dev, staging y prod idénticos), revisión de cambios por pull request, auditoría, recreación rápida en DR y detección de desviaciones (drift).

Terraform en Google Cloud

Terraform (HashiCorp) es la herramienta de IaC de referencia en Google Cloud y viene preinstalada en Cloud Shell. Es declarativa: describes el estado deseado y Terraform calcula qué crear, cambiar o borrar.

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 8.0"
    }
  }
  backend "gcs" {
    bucket = "mi-proyecto-tfstate"
    prefix = "prod/red"
  }
}

provider "google" {
  project = var.project_id
  region  = "europe-southwest1"
}

resource "google_compute_network" "vpc" {
  name                    = "vpc-prod"
  auto_create_subnetworks = false
}

Ciclo de trabajo: terraform init (descarga proveedores y configura el backend) → terraform plan (muestra qué cambiará) → terraform apply (aplica) → terraform destroy (borra todo lo gestionado). Añade terraform fmt y terraform validate en el pipeline.

Estado remoto: Terraform guarda en el fichero de estado el mapeo entre tu código y los recursos reales. En equipo, nunca en local:

• Guárdalo en un bucket de Cloud Storage con el backend gcs. Google recomienda activar el versionado de objetos (recuperar estados anteriores), uniform bucket-level access y public access prevention.
• El backend gcs bloquea el estado mientras alguien ejecuta apply, así dos personas no lo corrompen.
• El estado puede contener secretos en claro: restringe el acceso al bucket con IAM y considera CMEK.
• Separa estados por entorno o por componente (prefix distinto) para limitar el radio de impacto de un error.

Módulos: agrupan recursos reutilizables (una «VPC estándar», un «proyecto con sus APIs y presupuesto»). Google publica módulos probados en el Cloud Foundation Toolkit (terraform-google-modules) y en Cloud Foundation Fabric, útiles para montar una landing zone.

Infrastructure Manager

Infrastructure Manager (Infra Manager) es el servicio gestionado de Google que ejecuta Terraform por ti:

• Despliega configuraciones de Terraform desde un bucket de Cloud Storage, un repositorio Git o un directorio local.
• Ejecuta Terraform en un entorno efímero de Cloud Build y guarda el estado, la configuración y los logs de cada revisión en Cloud Storage.
• Conceptos: deployments (unidad gestionada), revisions (cada cambio aplicado) y previews (equivalente a plan).
• Solo aprovisiona infraestructura; las aplicaciones se despliegan con Cloud Build, Cloud Deploy u otras herramientas.
• Es el motor de despliegue de Application Design Center. Sustituye al antiguo Deployment Manager (plantillas en YAML/Jinja/Python), que encontrarás en material viejo.

Config Connector

Config Connector es un complemento de Kubernetes que permite gestionar recursos de Google Cloud (buckets, bases de datos Cloud SQL, Pub/Sub, IAM…) como recursos personalizados de Kubernetes (CRD). Aplicas un YAML con kubectl y el controlador crea o reconcilia el recurso en Google Cloud de forma continua (si alguien lo cambia a mano, lo devuelve al estado declarado). Encaja con flujos GitOps (Config Sync). Config Controller es la versión alojada y gestionada por Google.

Policy as code

Validar la infraestructura contra reglas antes de aplicarla:

• gcloud beta terraform vet: comprueba un plan de Terraform contra políticas de la organización (bibliotecas de restricciones) y puede detener el pipeline si hay violaciones.
• Organization Policy (incluidas las custom constraints): el control preventivo definitivo en la jerarquía de recursos (módulo 7).
• Policy Controller (basado en OPA Gatekeeper) para clústeres de GKE.
• Revisión por pull request + terraform plan en el pipeline como paso obligatorio.

Catálogo de servicios y aprovisionamiento (apartado 4.1)

La idea: que los equipos de desarrollo aprovisionen por autoservicio soluciones ya aprobadas (con seguridad, red y etiquetado correctos) sin abrir tickets al equipo de plataforma. Opciones en Google Cloud:

• Application Design Center: los equipos de plataforma crean plantillas de aplicación con las políticas y buenas prácticas incorporadas, las publican en catálogos compartidos y los desarrolladores las personalizan y despliegan (vía Infrastructure Manager). Gemini Cloud Assist ayuda a diseñarlas en lenguaje natural.
• Service Catalog: producto más antiguo para publicar soluciones (configuraciones de Terraform, enlaces) a usuarios de la organización.
• Módulos de Terraform versionados en un repositorio interno + pipeline, el enfoque más extendido.
• Project factory: automatizar la creación de proyectos con su presupuesto, APIs, IAM y red (módulo de CFT).

Gestión de APIs: Apigee y API Gateway (apartado 5.1)

Apigee

Apigee es la plataforma completa de gestión de APIs de Google. Se sitúa delante de tus backends (en Google Cloud, en otras nubes u on-premises) como un proxy y añade:

• API proxies: un proxy endpoint (lo que ve el consumidor) y un target endpoint (el backend), con políticas en el flujo de petición y respuesta: transformación (JSON/XML), enrutado, caché, mediation.
• Seguridad: validación de API keys, OAuth 2.0, JWT, protección frente a amenazas en el contenido (JSON/XML), y Advanced API Security para detectar abusos y configuraciones inseguras.
• Control de tráfico: Quota (número de llamadas por consumidor y periodo, p. ej. 1.000/día para el plan gratuito) y Spike Arrest (suaviza picos para proteger el backend).
• API products y developer apps: empaquetas APIs con cuotas y planes; los desarrolladores externos se registran en un developer portal y obtienen credenciales.
• Monetización: planes de tarifa y facturación por uso de las APIs.
• Analítica: tráfico, latencia, errores, consumidores más activos.
• Despliegue: Apigee gestionado por Google en Google Cloud o Apigee hybrid (plano de ejecución en tu Kubernetes, on-premises u otra nube; plano de gestión en Google Cloud).
• Modelos de precio: evaluación, pay-as-you-go y suscripción; consulta cloud.google.com/apigee/pricing.

Buenas prácticas de diseño de APIs que el examen puede mencionar: versionado (/v1/), diseño orientado a recursos (guía de diseño de APIs de Google), paginación, códigos de error coherentes, especificación OpenAPI, autenticación con OAuth 2.0 en lugar de solo API keys cuando hay datos de usuario, cuotas por consumidor y no exponer directamente los backends.

API Gateway

API Gateway es una alternativa ligera y serverless para exponer backends de Google Cloud (Cloud Run, Cloud Run functions, App Engine) con una especificación OpenAPI (2.0, y 3.x con algunas limitaciones): autenticación con API keys, JWT o cuentas de servicio, cuotas básicas y monitorización. Sin portal de desarrolladores, sin monetización, sin analítica avanzada ni transformaciones complejas.

Frameworks de pruebas (apartado 5.1)

La pirámide de pruebas: muchas pruebas unitarias (rápidas, aisladas, en cada commit), menos pruebas de integración (componentes juntos, contra dependencias reales o emuladas) y pocas pruebas extremo a extremo (lentas y frágiles, sobre un entorno completo).

Consejos de arquitecto: pruebas en cada pull request (trigger de PR), entorno de staging creado con la misma IaC que producción, datos de prueba sin datos personales reales (o enmascarados con Sensitive Data Protection) y pruebas de DR y de carga antes de eventos críticos.

Interactuar con Google Cloud de forma programática (apartado 5.2)

Cloud Shell, Cloud Shell Editor y Cloud Code

• Cloud Shell: terminal en el navegador sobre una VM efímera con gcloud, kubectl, terraform, bq, Docker, Git y lenguajes habituales ya instalados y autenticados con tu usuario. Incluye 5 GB de disco persistente en tu $HOME (se borra tras 120 días sin usar Cloud Shell), una cuota semanal por defecto de 50 horas y sesiones de hasta 12 horas. No es para cargas de producción ni procesos largos.
• Cloud Shell Editor: un editor basado en Code OSS (la base de VS Code) dentro de Cloud Shell, con Cloud Code y Gemini Code Assist integrados.
• Cloud Code: extensiones para VS Code y los IDE de JetBrains (y Cloud Shell Editor) para desarrollar para Kubernetes y Cloud Run: plantillas, despliegue y depuración, ejecución local de Cloud Run, integración con Skaffold y con Secret Manager.

Google Cloud SDK y CLI

Consejos: gcloud config configurations para alternar entre proyectos o cuentas, --format y --filter para scripts, y --impersonate-service-account para actuar como una cuenta de servicio sin descargar claves.

Emuladores

Los emuladores locales permiten desarrollar y probar sin coste, sin red y sin tocar datos reales:

Tras arrancarlo, las bibliotecas cliente se dirigen al emulador mediante variables de entorno (por ejemplo PUBSUB_EMULATOR_HOST, SPANNER_EMULATOR_HOST); gcloud beta emulators pubsub env-init imprime las que necesitas. Limitaciones: no reproducen todo (IAM, rendimiento, algunas funciones), así que las pruebas finales se hacen contra el servicio real en un proyecto de pruebas.

Bibliotecas cliente y buenas prácticas de acceso a las APIs

• Bibliotecas cliente: usa las Cloud Client Libraries idiomáticas de cada lenguaje (Python, Java, Go, Node.js, C#, Ruby, PHP, C++). Gestionan autenticación, reintentos y paginación. Las Google API Client Libraries genéricas son para APIs sin biblioteca específica.
• Application Default Credentials (ADC): el mecanismo con el que las bibliotecas encuentran credenciales sin tocar el código. Orden de búsqueda: 1) la variable GOOGLE_APPLICATION_CREDENTIALS; 2) las credenciales creadas con gcloud auth application-default login (desarrollo local); 3) la cuenta de servicio adjunta al recurso (VM, Cloud Run, GKE con Workload Identity Federation for GKE) a través del servidor de metadatos. En producción, cuenta de servicio adjunta y nada de claves JSON descargadas; fuera de Google Cloud, Workload Identity Federation.
• Mínimo privilegio: una cuenta de servicio por aplicación con solo los roles que necesita.
• Cuotas y límites: cada API tiene cuotas por proyecto (peticiones por minuto, recursos). Consúltalas en la consola (IAM y administración > Cuotas), pide aumentos con antelación y diseña para recibir HTTP 429 (RESOURCE_EXHAUSTED).
• Reintentos con backoff exponencial y jitter ante errores transitorios (429, 500, 503): esperar 1 s, 2 s, 4 s… más un componente aleatorio, con un máximo de intentos y de espera. Reintenta solo operaciones idempotentes (o haz que lo sean). Las bibliotecas cliente ya lo implementan para muchos casos.
• Eficiencia: operaciones por lotes (batch), paginación, peticiones parciales con fields, y caché de resultados cuando proceda.
• Operaciones de larga duración (LRO): muchas APIs devuelven una operación que hay que consultar (polling) hasta que termina.

Gemini Cloud Assist y Gemini Code Assist

En el examen, Gemini Cloud Assist aparece como apoyo al diseño y a la operación (apartados 1.2 y 5.1) y Gemini Code Assist como mejora de la productividad del desarrollador. El criterio sigue siendo humano: revisa lo que genera, igual que revisarías un pull request.

Patch management: VM Manager

Mantener parcheadas las VMs es responsabilidad tuya en IaaS (modelo de responsabilidad compartida). VM Manager agrupa tres servicios para flotas de Compute Engine:

• Patch (OS patch management): parcheo bajo demanda o programado (patch deployments) de Linux y Windows, con filtros por etiquetas o zonas, despliegue gradual por zonas, scripts previos y posteriores, y informes de cumplimiento de parches.
• OS inventory management: qué sistema operativo y paquetes tiene cada VM.
• OS policies: estado deseado de configuración (instalar, quitar o mantener actualizados paquetes).

Requisitos: habilitar la OS Config API en el proyecto, activar el agente OS Config en las VMs mediante metadatos (viene preinstalado en la mayoría de imágenes de Google) y que las VMs puedan llegar a los repositorios de paquetes (con Cloud NAT o Private Google Access si no tienen IP pública).

Alternativa de fondo: infraestructura inmutable. En lugar de parchear VMs vivas, construyes una imagen nueva con los parches y haces un rolling update del MIG. En GKE y Cloud Run el parcheo del sistema subyacente lo gestiona Google (en GKE, con los canales de versiones y las ventanas de mantenimiento).

Trampas típicas del examen

• Container Registry está retirado: la respuesta actual es Artifact Registry. Cloud Source Repositories no está disponible para clientes nuevos.
• Cloud Build = CI (construir y probar); Cloud Deploy = CD (promover releases entre entornos con aprobaciones y rollback). Si el enunciado pide «promoción entre entornos, aprobaciones y rollback auditables», es Cloud Deploy.
• Builds que necesitan red privada → private pool, no el default pool.
• Estado de Terraform en local o en Git → mal. En un bucket de Cloud Storage con versionado y bloqueo.
• «Terraform gestionado por Google» → Infrastructure Manager; Deployment Manager es el heredado.
• «Recursos de Google Cloud como YAML de Kubernetes / GitOps» → Config Connector.
• Apigee para APIs externas con portal, cuotas por consumidor, monetización y analítica; API Gateway para exponer backends serverless de forma sencilla.
• Canary reduce el riesgo con tráfico real; blue/green da rollback instantáneo; rolling no necesita capacidad extra.
• Emuladores para pruebas locales de Pub/Sub, Firestore, Spanner y Bigtable; no sustituyen la prueba final en la nube.
• Claves JSON de cuentas de servicio en el código o en el repositorio → nunca. ADC con cuenta de servicio adjunta o Workload Identity Federation.
• Errores 429/503 → reintentos con backoff exponencial y jitter, no reintentos inmediatos en bucle.
• gsutil funciona, pero la herramienta recomendada es gcloud storage.
• Parches de SO a escala → VM Manager.

Resumen

• DevOps se mide con DORA: frecuencia de despliegue, tiempo de entrega, tasa de cambios fallidos y tiempo de recuperación.
• Cloud Build ejecuta pasos en contenedores definidos en cloudbuild.yaml, lanzados por triggers (push, tag, PR, Pub/Sub, webhook); los private pools dan acceso a redes privadas.
• Artifact Registry guarda imágenes y paquetes (repositorios standard, remote y virtual) y se integra con Artifact Analysis y Binary Authorization.
• Cloud Deploy gestiona delivery pipelines, targets, releases, rollouts, aprobaciones, promociones, canary y rollback.
• Elige la estrategia de despliegue según riesgo, coste y rollback: rolling, blue/green, canary, A/B, feature flags.
• Terraform con estado remoto en Cloud Storage (versionado y bloqueo), módulos reutilizables y policy as code; Infrastructure Manager lo ejecuta de forma gestionada; Config Connector lo lleva a Kubernetes.
• Apigee para gestión completa de APIs (seguridad, cuotas, productos, portal, monetización, analítica, hybrid); API Gateway para casos sencillos serverless.
• Herramientas: Cloud Shell y su editor, Cloud Code, gcloud, gcloud storage (antes gsutil), bq, emuladores y Cloud Client Libraries con ADC, cuotas y backoff exponencial.
• Gemini Cloud Assist ayuda a diseñar y operar; Gemini Code Assist, a programar. VM Manager parchea y audita flotas de VMs.

Practica lo aprendido

Documentación oficial para ampliar

• Cloud Build overview
• Cloud Build private pools overview
• Cloud Deploy — Deploy an app to Cloud Run (quickstart)
• Cloud Deploy — Canary deployment strategy
• Store Terraform state in a Cloud Storage bucket
• Infrastructure Manager overview
• Application Design Center overview
• Apigee overview
• VM Manager overview
• Gemini Code Assist overview