Google PCD: Arquitectura de aplicaciones nativas de la nube y selección de servicios — Guía de estudio

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Developer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La arquitectura de aplicaciones nativas de la nube en Google Cloud se centra en construir servicios resilientes y sin estado que escalan horizontalmente, minimizan el trabajo operativo y adoptan servicios administrados cuando es apropiado. La selección efectiva de servicios requiere comprender las compensaciones entre control, portabilidad, rendimiento, costo y responsabilidad operativa. Esta sección presenta principios y patrones que te ayudan a diseñar, modernizar y operar aplicaciones para usuarios globales con una fiabilidad predecible.

Principios y Opciones de Arquitectura Nativos de la Nube

• Diseño sin estado y de doce factores

  • Base de código, dependencias y build-release-run: Fija las dependencias exactas, crea artefactos inmutables y separa la compilación del lanzamiento. Las imágenes de contenedor y los pipelines de Cloud Build garantizan lanzamientos reproducibles.
  • Configuración en el entorno: Externaliza la configuración usando variables de entorno, Secret Manager, Kubernetes Secrets o metadatos de instancia para Compute Engine. No incluyas credenciales ni configuraciones por despliegue en las imágenes. Para los grupos de instancias administrados de Compute Engine, usa los metadatos de la plantilla de instancia para los valores por despliegue.
  • Servicios de respaldo: Trata las bases de datos, colas y cachés como recursos adjuntos. Prefiere los servicios administrados (Cloud SQL, Cloud Spanner, Firestore, Memorystore, Pub/Sub) para reducir la carga operativa.
  • Procesos sin estado: Escala añadiendo instancias; almacena el estado de la sesión externamente (Memorystore for Redis, Firestore o Spanner). Escribe los logs en stdout/stderr o en archivos de log recopilados por el agente de Cloud Logging.
  • Desechabilidad: El arranque/apagado rápido permite un escalado rápido y actualizaciones continuas (rolling updates). Maneja SIGTERM para un apagado ordenado (graceful shutdown).
  • Logs como flujos de eventos: Emite logs estructurados; usa Cloud Logging para la ingesta y Cloud Monitoring para las alertas.

• Compensaciones de arquitectura

  • Monolito
    • Pros: Desarrollo/pruebas simplificados, menos fronteras de red, unidad de despliegue única.
    • Contras: Entrega independiente más lenta, restricciones de escalado, acoplamiento fuerte entre dominios.
    • Modos de fallo: Una ruta crítica (hot path) puede consumir recursos compartidos; las regresiones impactan a todas las funcionalidades.
  • Monolito modular
    • Pros: Límites claros entre módulos internos, ruta de refactorización hacia servicios, un único desplegable.
    • Contras: Aún restringido por el despliegue y la base de datos monolíticos.
    • Usar para equipos que están madurando los límites de dominio antes de extraer servicios.
  • Microservicios
    • Pros: Capacidad de despliegue independiente, escalado específico, autonomía del equipo, aislamiento de fallos con mamparos (bulkheads) adecuados.
    • Contras: Complejidad de los sistemas distribuidos, consistencia, observabilidad y sobrecarga operativa.
    • Modos de fallo: Fallos en cascada a través de llamadas síncronas; deriva del esquema (schema drift); redes muy comunicativas (chatty networks).
  • Orientada a eventos
    • Pros: Acoplamiento débil, resiliencia asíncrona, búfer natural, auditabilidad a través de logs/flujos.
    • Contras: Complejidad en la depuración, consistencia eventual, la semántica de ordenamiento y de ’exactamente una vez’ (exactly-once) es difícil.
    • Pub/Sub proporciona entrega ‘al menos una vez’ (at-least-once); diseña consumidores idempotentes.
  • Serverless (Cloud Run, Cloud Functions, App Engine)
    • Pros: Mínimas operaciones, escalado a cero, autoescalado por solicitud, seguridad y telemetría integradas.
    • Contras: Límites de tiempo de ejecución y concurrencia, arranques en frío (cold starts), restricciones específicas de la plataforma.
    • Usar para cargas de trabajo en ráfagas (bursty), backends para móviles/web y procesamiento de eventos.

Patrones de Comunicación y Selección de Servicios

• Llamadas síncronas vs. asíncronas

  • Síncronas
    • Usar para APIs de solicitud/respuesta que requieren resultados inmediatos.
    • Protocolos: gRPC (HTTP/2, streaming, Protobuf compacto; excelente para ancho de banda móvil y contratos fuertes), HTTP/JSON (amplia compatibilidad; depuración más simple).
    • Riesgos: Acoplamiento fuerte y amplificación de la latencia; usa tiempos de espera (timeouts), reintentos con fluctuación (jitter) y cortacircuitos (circuit breakers).
  • Asíncronas
    • Usa Pub/Sub o Cloud Tasks cuando el trabajo puede ser diferido o procesado en lotes.
    • Beneficios: Suaviza los picos, aísla los fallos, mejora la latencia percibida por el usuario a través de la finalización eventual.
    • Riesgos: Requiere idempotencia y acciones de compensación; la visibilidad del trabajo en curso debe ser implementada.

• Criterios de selección de servicios en Google Cloud

  • Control y portabilidad
    • Compute Engine: Control total de la VM e imágenes personalizadas; mayor carga operativa.
    • GKE: Contenedores portátiles y opciones de malla de servicios (service mesh); autoescalado robusto; responsabilidad compartida.
    • Cloud Run: Alta portabilidad para contenedores con mínimas operaciones; escalado a cero; orientado a solicitudes.
    • App Engine: PaaS dogmática (opinionated) con enrutamiento y escalado integrados; la ruta más rápida para ciertos lenguajes.
  • Escalado y latencia
    • Global HTTP(S) Load Balancing con Cloud CDN para aceleración en el borde (edge).
    • Almacenes de datos:
      • Cloud Spanner: Consistencia global, escalado horizontal, disponibilidad multirregional del 99.999%.
      • Cloud SQL: BD relacional administrada, regional, réplicas de lectura incluyendo transregionales (cross-region).
      • Firestore: BD de documentos con disponibilidad global en multirregión, consistencia fuerte para documentos individuales.
      • Cloud Bigtable: Baja latencia, escalado masivo para casos de uso de columna ancha (wide-column).
      • Memorystore: Caché de baja latencia para rutas críticas (hot paths) y sesiones.
  • Responsabilidad operativa
    • Prefiere servicios administrados para las preocupaciones principales (disponibilidad, aplicación de parches, copias de seguridad, actualizaciones).
    • La autogestión ofrece flexibilidad pero añade trabajo operativo y superficie de fallo (p. ej., Kafka autohospedado vs. Pub/Sub).
  • Movimiento e integración de datos
    • Usa conectividad nativa de VPC, Private Service Connect y el balanceo de carga HTTP(S) interno para un acceso privado de baja latencia.
    • Descubrimiento de servicios: Nombres de Kubernetes Service dentro de un clúster; DNS interno de Compute Engine para VMs.

Ejemplo de Kubernetes Service (descubrimiento de nombres en el clúster): apiVersion: v1 kind: Service metadata: name: image-resize spec: selector: app: image-resize ports:

• port: 80 targetPort: 8080 type: ClusterIP

Patrones de Delimitación, Compatibilidad y Confiabilidad

• Límites de dominio y propiedad

  • Usa el diseño guiado por el dominio (domain-driven design) para definir contextos delimitados (bounded contexts). Cada servicio es dueño de sus datos y publica APIs/eventos como contratos.
  • Evita las bases de datos compartidas entre servicios; utiliza interfaces bien definidas y propagación de eventos.
  • La propiedad implica guardias (on-call), SLOs, cadencia de lanzamientos y responsabilidad presupuestaria por cada servicio.

• Contratos de API y retrocompatibilidad

  • Versiona las APIs explícitamente (p. ej., v1 en la ruta o en la cabecera). Prefiere cambios aditivos; evita romper campos o comportamientos.
  • Usa pruebas de contrato guiadas por el consumidor (consumer-driven contract tests) y lanzamientos canary.
  • Descontinúa (deprecate) con plazos definidos y telemetría sobre el uso.
  • Para clientes móviles, espera versiones de cola larga (long tail); mantén múltiples versiones de la API de forma concurrente.

• Aislamiento de fallos y resiliencia

  • Bulkheads (Mamparos): Aísla los recursos por servicio o clase de prioridad (pools de nodos, grupos de instancias, cuotas separados). Evita que una funcionalidad de mejor esfuerzo (best-effort) sature las rutas críticas.
  • Circuit breakers (Cortacircuitos): Se activan tras fallos consecutivos a una dependencia; liberan carga y permiten una ventana de recuperación. Impleméntalos a través de un service mesh (p. ej., Envoy), políticas de gateway o librerías.
  • Timeouts y reintentos: Usa exponential backoff truncado con jitter; asegúrate de que los manejadores (handlers) sean idempotentes.
  • Degradación controlada (Graceful degradation): Omite componentes de UI no críticos en caso de timeouts; sirve datos cacheados o aproximados en lugar de errores.
  • Health checks y readiness probes: Dirige el tráfico solo a instancias listas (ready); usa liveness para la autorreparación (self-healing).

Ejemplo de exponential backoff truncado (HTTP 429): retry = 0 max_retry = 5 base = 0.5 while retry < max_retry: resp = fetch_gcs_object() if resp.status_code == 200: break if resp.status_code in (429, 500, 503): sleep = min(8, base * (2 ** retry)) + random.uniform(0, 0.25) time.sleep(sleep) retry += 1 else: raise Exception(“Error no reintentable”)

Consideraciones operativas y globales

• Patrones multirregionales para usuarios globales

  • Frontend global: Utilice el balanceo de cargas de HTTP(S) externo y global con IP anycast y Cloud CDN para el contenido estático. Configure el almacenamiento en caché negativo y la validación para reducir la carga en el origen.
  • Plano de datos:
    • Para una disponibilidad de base de datos de cinco nueves y una latencia de lectura global minimizada, utilice una instancia multirregional de Cloud Spanner (p. ej., nam-asia-eur1) y aprovisione nodos suficientes para el cómputo y el cuórum (mínimo tres nodos para producción).
    • Para patrones con uso intensivo de lectura sin una consistencia global estricta, considere una región primaria con réplicas de lectura interregionales; acepte una mayor latencia de escritura entre continentes.
  • Plano de aplicación:
    • Despliegue servicios sin estado en múltiples regiones con autoescalado (GKE o Cloud Run). Utilice servicios de backend y grupos de extremos de red por región.
    • Enrute por latencia respetando las restricciones de residencia de datos y cumplimiento normativo.
  • Cachés: Coloque Memorystore o cachés de borde cerca de los usuarios para absorber el tráfico de lectura y proteger los orígenes.

• Gestionado vs. autogestionado

  • Utilice Cloud Monitoring para las métricas, Cloud Logging para los registros, Cloud Trace/Profiler para la latencia y los puntos calientes de CPU/memoria. Cree políticas de alerta para las tasas de consumo del SLO y verificaciones de tiempo de actividad para la disponibilidad externa.
  • Si una plataforma de observabilidad existente debe seguir siendo el sistema de registro, ingiera primero con Cloud Logging para obtener alertas de baja latencia y luego exporte a través de receptores (sinks) a la plataforma externa.

• Modernización y migración incremental

  • Patrón Strangler: Coloque el monolito detrás de una puerta de enlace (gateway); enrute puntos de conexión específicos a nuevos servicios. Reemplace gradualmente las capacidades.
  • Ramificación por abstracción: Introduzca una interfaz alrededor de una dependencia e intercambie la implementación detrás de ella (p. ej., base de datos o almacenamiento).
  • Capa anticorrupción: Traduzca entre los modelos de datos heredados y los nuevos contextos delimitados.
  • Migración de datos: Utilice escrituras duales con verificación o event sourcing para rellenar datos históricos; planifique las transiciones con controles de contrapresión.
  • Entrega por fases: Reemplace funcionalidades por etapas para minimizar el riesgo para el negocio; mida continuamente los SLO.

• Revisiones de diseño y evaluación de contrapartidas

  • Seguridad: Modelo de amenazas, privilegio mínimo en IAM, cuentas de servicio en lugar de claves incrustadas (utilice Application Default Credentials en GCE/GKE/Cloud Run), CMEK donde sea necesario, conectividad privada, WAF y límites de frecuencia, escaneo de vulnerabilidades y de seguridad web.
  • Fiabilidad: Defina SLO y presupuestos de errores, planes de conmutación por error (failover) multirregionales, margen de capacidad, ejercicios de caos, mapas de dependencias.
  • Rendimiento: Análisis de latencia de cola, pruebas de carga en el borde y en el origen, reutilización de conexiones (HTTP/2, gRPC), compresión, estrategia de caché.
  • Costo: Dimensionar correctamente los recursos, políticas de autoescalado, descuentos por uso continuo, escalado a cero para cargas de trabajo intermitentes, egreso y descarga a CDN.
  • Operaciones: Runbooks, reversiones (rollbacks), entrega progresiva (canary, azul/verde), política como código, copias de seguridad y pruebas de DR, integración de la respuesta a incidentes.

Escenario de problema práctico

Nimbus Retail está lanzando una plataforma global de comercio electrónico con imágenes personalizadas, objetivos estrictos de latencia por debajo de 200 ms en p95 a nivel mundial y un requisito de disponibilidad del 99.999 % para la base de datos de pedidos. También deben mantener su SIEM existente mientras mejoran la velocidad de las alertas.

1. Establecer una base de datos global y de alta disponibilidad usando Cloud Spanner

• Acción: Crear una instancia multirregional de Spanner en nam-asia-eur1 con al menos tres nodos y dividir las tablas en esquemas intercalados apropiados para la localidad.
• Justificación: Spanner multirregional ofrece cinco nueves y baja latencia de lectura a través de réplicas en tres continentes; tres o más nodos aseguran suficiente capacidad de cómputo y de cuórum de réplicas.

Ejemplo:

undefined

2. Despliegue global del frontend y la API

• Acción: Utilizar el balanceo de cargas de HTTP(S) externo y global con Cloud CDN para los activos estáticos y el enrutamiento dinámico a los backends regionales (servicios de GKE en us-central1, europe-west1, asia-east1).
• Justificación: El VIP anycast minimiza el RTT (tiempo de ida y vuelta); CDN almacena en caché las imágenes cerca de los usuarios; los servicios de backend distribuyen las solicitudes a la región funcional más cercana.

3. Servicios sin estado en GKE con descubrimiento dentro del clúster

• Acción: Desplegar los servicios de redimensionamiento de imágenes y de API en GKE con autoescalado horizontal de pods y servicios de tipo ClusterIP para el acceso basado en nombres dentro del clúster; exponer los puntos de conexión públicos a través de un Ingress.
• Justificación: Los pods sin estado permiten un escalado elástico; el servicio de Kubernetes abstrae las IP de los pods y proporciona un DNS estable, reduciendo el acoplamiento del cliente.

4. Procesamiento de imágenes impulsado por eventos

• Acción: Publicar las tareas de procesamiento de imágenes en Pub/Sub; ejecutar servicios de Cloud Run suscritos mediante push para procesar objetos almacenados en Cloud Storage. Implementar un retroceso exponencial truncado con fluctuación (jitter) en los errores 429/5xx de GCS.
• Justificación: Pub/Sub amortigua los picos y aísla las fallas; Cloud Run escala por mensaje; el retroceso reduce la amplificación de errores y ayuda a que los buckets se calienten gradualmente.

5. Observabilidad y alertas rápidas

• Acción: Utilizar Cloud Logging y Cloud Monitoring para ingerir registros y métricas, definir verificaciones de tiempo de actividad para las API y crear políticas de alerta sobre tasas de error y latencia. Configurar un receptor de registros (log sink) para exportar al SIEM existente.
• Justificación: La telemetría nativa proporciona alertas de baja latencia y verificaciones de tiempo de actividad gestionadas; la exportación preserva el SIEM centralizado sin sacrificar la velocidad de las alertas.

6. Configuración y secretos externalizados

• Acción: Almacenar la configuración no secreta en ConfigMaps; los secretos y las claves de API en Secret Manager con Workload Identity para GKE. Para cualquier trabajo basado en Compute Engine, utilizar los metadatos de la instancia para valores específicos de cada despliegue.
• Justificación: La configuración externalizada permite imágenes inmutables y ajustes específicos del entorno; evita incrustar secretos; los metadatos soportan la varianza de las VM sin cambios en el código.

7. Aislamiento de fallas y degradación elegante

• Acción: Aplicar mamparos (bulkheads) con grupos de nodos separados para las cargas de trabajo de personalización de mejor esfuerzo; hacer cumplir presupuestos de solicitudes y disyuntores (circuit breakers) para los servicios de personalización. En la interfaz de usuario, omitir los widgets no críticos cuando las dependencias agoten el tiempo de espera.
• Justificación: Aislar la capacidad evita que las funcionalidades de mejor esfuerzo acaparen los recursos del proceso de pago; los disyuntores limitan el radio de impacto; la degradación elegante preserva los flujos principales.

8. Contratos de API y compatibilidad

• Acción: Definir contratos gRPC para clientes móviles (v1) con transcodificación a HTTP/JSON para la web; adoptar cambios aditivos y mantener al menos dos versiones durante el despliegue móvil.
• Justificación: gRPC reduce el ancho de banda y proporciona un tipado fuerte; la transcodificación facilita la integración con navegadores y socios; el versionado preserva la compatibilidad con versiones anteriores.

9. Seguridad e identidad

• Acción: Utilizar cuentas de servicio de Google por servicio con el privilegio mínimo en IAM; depender de Application Default Credentials. Habilitar Cloud Armor para protecciones en el borde y forzar TLS en todas partes.
• Justificación: Workload Identity elimina los riesgos de la gestión de claves; el WAF y los límites de frecuencia mitigan el abuso; el cifrado en tránsito es predeterminado y obligatorio.

10. Entrega continua y seguridad en los lanzamientos

• Acción: Implementar lanzamientos canary con división de tráfico basada en porcentajes en el balanceador de cargas y reversión automática ante alertas de consumo del SLO. Mantener entornos azul/verde por región.
• Justificación: La entrega progresiva limita el riesgo; el modelo azul/verde regional acelera la reversión y permite migraciones de esquema seguras alineadas con las API versionadas.

Todos los dominios · Cómputo →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →