Google PCA: Migración, Modernización y Estrategia de Nube Híbrida — Guía de estudio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Architect — 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

Una estrategia exitosa de migración, modernización y nube híbrida alinea las elecciones de plataforma con los resultados de negocio, a la vez que gestiona los riesgos de disponibilidad, integridad de los datos, latencia, seguridad y coste. El camino equilibra el realojamiento rápido (rehost) para reducir el riesgo del centro de datos con la refactorización (refactor) selectiva para capturar los beneficios de la nube. El modelo operativo debe evolucionar junto con la tecnología para mantener las mejoras. Esta sección proporciona una guía pragmática para la evaluación y la planificación por oleadas, los marcos de decisión, las mecánicas de migración, la integración híbrida, los patrones de modernización, las consideraciones sobre políticas y multinube, y la optimización posmigración, con énfasis en los modos de fallo y las contrapartidas (trade-offs).

Evaluación, preparación y planificación por oleadas

Descubrimiento y análisis de dependencias
- Inventariar cargas de trabajo, versiones, kernels del SO, almacenamiento, IAM y clasificaciones de datos. Mapear las dependencias en los flujos web→API→BD, servicios compartidos (LDAP/AD, DNS, NTP), pipelines de lotes (batch) y API externas.
- Utilizar el perfilado de aplicaciones y el trazado distribuido en los entornos de premigración para descubrir dependencias ocultas y latencia de cola larga (long-tail). Activar VPC Flow Logs y la instrumentación a nivel de aplicación (Cloud Logging, Cloud Monitoring, Cloud Trace).
- Identificar los límites de estado y la gravedad de los datos (data gravity): tamaño, patrones de acceso (mezcla R/W), expectativas de consistencia y topología de replicación.
Preparación y habilidades
- Evaluar las habilidades en fundamentos de la nube, IaC, CI/CD, SRE, seguridad, redes y bases de datos. Definir una hoja de ruta de formación y certificación basada en roles y presupuestar tiempo para la capacitación (upskilling) y las guardias en modo de aprendizaje (shadow on-calls).
- Establecer una landing zone (proyectos, carpetas, Shared VPC, políticas de organización, receptores de auditoría, estrategia de CMEK) antes de la primera oleada.
Planificación de oleadas de migración
- Agrupar las aplicaciones en oleadas por afinidad y radio de impacto (blast radius): datos compartidos, dependencias síncronas y ventanas de cambio. Incluir las dependencias de alto riesgo en la misma oleada o simularlas (stub) con contratos de API bien definidos.
- Definir por oleada los SLO, RTO/RPO, criterios de reversión (rollback) y puertas de validación (comprobaciones de esquema, recorridos de usuario sintéticos, umbrales de rendimiento).
- Preparar runbooks y la gestión de cambios: pasos de transición (cutover), puntos de control, reversión (rollback) y recopilación de evidencias para la aprobación.
Compatibilidad, licenciamiento y establecimiento de bases de rendimiento
- Validar el soporte del SO y del middleware en Compute Engine y en los servicios gestionados. Verificar los términos de las licencias comerciales, las restricciones de BYOL, los requisitos de los módulos del kernel y las afinidades de hardware.
- Capturar las bases de rendimiento de CPU, memoria, IOPS, rendimiento (throughput) y latencia con valores pico y de percentil 95 para dimensionar los recursos de destino y validar los beneficios.
Gobernanza de datos
- Clasificar los datos PII/PCI. Planificar la desidentificación o la tokenización en la ingesta utilizando Cloud DLP. Definir las políticas de auditoría, retención y exportación antes de que se almacene el primer log de producción.

Modos de fallo comunes: dependencias síncronas desconocidas que causan tiempos de espera en cascada después de la transición (post-cutover); rangos de IP superpuestos que bloquean la conectividad; brechas en el cumplimiento de las licencias; falta de paridad en la reversión (rollback) cuando las mutaciones de datos no se pueden deshacer.

Patrones de migración, movimiento de datos y transición (cutover)

Marco de decisión (las 6 R)
- Rehost (realojar): mover tal cual a Compute Engine. El tiempo más rápido para llegar a la nube, cambio mínimo. Riesgo: arrastra la deuda técnica y un dimensionamiento ineficiente.
- Replatform (replataformar): pequeños cambios para adoptar servicios administrados (p. ej., Cloud SQL, Cloud Load Balancing). Beneficios operativos más rápidos con pocos cambios en el código.
- Refactor (refactorizar): descomponer o contenerizar para GKE/Cloud Run; adoptar patrones orientados a eventos. El mayor beneficio a largo plazo con riesgo en la entrega.
- Retire (retirar): eliminar sistemas no utilizados después de que se demuestre la ausencia de uso y dependencias.
- Retain (retener): mantener on-premise por motivos regulatorios o de latencia; integrar a través de un modelo híbrido.
- Relocate (reubicar): mover cargas de trabajo de vSphere a Google Cloud VMware Engine; preserva las herramientas y minimiza los cambios.
Herramientas de migración de cómputo y bases de datos
- Migrate to Virtual Machines acelera el realojamiento (rehost) en Compute Engine preservando los discos y la configuración de red. Valide la compatibilidad del SO invitado y los controladores del kernel.
- Database Migration Service proporciona replicación homogénea en línea (p. ej., MySQL, PostgreSQL) a Cloud SQL con bajo tiempo de inactividad. Asegúrese de que la configuración de binlog/replicación sea correcta y que la latencia permita una puesta al día casi en tiempo real.
- Elija bases de datos que se ajusten a la carga de trabajo:
  - Cloud SQL para necesidades relacionales administradas; habilite el aumento automático de almacenamiento y supervise la CPU cerca del 75 % por núcleo; siga el retraso de la replicación (replication lag) y fragmente (shard) o escale verticalmente si se acerca a los umbrales.
  - Bigtable para la ingesta de series temporales de baja latencia y alto rendimiento (p. ej., datos de sensores).
  - Spanner para escala global y consistencia sólida; comprenda la dependencia del proveedor (lock-in) frente a la portabilidad.
- Movimiento de datos
  - Storage Transfer Service para transferencias continuas o programadas; paraleliza y es consciente de los reintentos.
  - Transfer Appliance para cargas masivas únicas (de decenas a cientos de TB) para reducir el tiempo y el riesgo de la red.
  - gsutil y cargas compuestas paralelas para conjuntos de datos de tamaño pequeño a mediano.
Migración en línea (online) vs. fuera de línea (offline)
- En línea (online): replicación continua con una transición (cutover) corta. Ventajas: tiempo de inactividad mínimo; Desventajas: requiere latencia y ancho de banda estables; evitar cuidadosamente la doble escritura.
- Fuera de línea (offline): instantánea (snapshot) e importación masiva. Ventajas: simple y predecible; Desventajas: el tiempo de inactividad es igual a la duración de la copia.
Planificación de la transición (cutover), reversión (rollback) y control del tiempo de inactividad
- Reduzca los TTL de DNS días antes de la transición, congele los cambios no esenciales y programe una ventana de mantenimiento.
- Ejecute puertas de validación: paridad de esquemas, sumas de verificación (checksums) o recuentos de filas, pruebas de humo (smoke tests) de la aplicación, tráfico canario y sondeos de rendimiento.
- Reversión (rollback): asegure cambios de esquema retrocompatibles, indicadores de funciones (feature flags) y la preservación de los datos de la fuente de verdad. Evite escrituras irreversibles hasta que se demuestre la estabilidad.
- Ejemplo de expansión de disco de VM con tiempo de inactividad mínimo:
  - Redimensione el disco en la Consola o CLI: gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
  - En Linux ext4: sudo resize2fs /dev/sdb
- Actualizaciones continuas (rolling updates) de aplicaciones con impacto mínimo en GKE:
  - kubectl set image deployment/echo-deployment echo-container=gcr.io/project/echo:v2

Modos de fallo comunes: pérdida de paquetes sobre Cloud VPN que interrumpe la replicación de la base de datos (use Dedicated Interconnect o Partner Interconnect), divergencia de doble escritura durante la transición, falta de verificaciones de estado (health checks) que detienen las actualizaciones continuas.

Identidad híbrida, conectividad e integración on-premise

Identidad
- Mantenga Active Directory como la fuente de verdad. Use Google Cloud Directory Sync para la sincronización de cuentas y grupos, y configure SSO con SAML para el acceso de los usuarios a Google Cloud.
- Otorgue el mínimo privilegio en IAM a través de roles, use cuentas de servicio para las cargas de trabajo y prefiera Workload Identity Federation en lugar de claves de larga duración.
Conectividad y enrutamiento híbridos
- Use Cloud VPN para necesidades iniciales de bajo rendimiento y pruebas; pase a Dedicated Interconnect para un ancho de banda sostenido, menor latencia y un rendimiento de replicación predecible. Despliegue adjuntos de VLAN redundantes y HA VPN o interconexiones dobles para mayor resiliencia.
- Asegúrese de que los rangos de IP de Google Cloud no se superpongan con los CIDR on-premise para preservar la accesibilidad de extremo a extremo.
- Aplique el acceso por niveles con reglas de firewall y etiquetas. Ejemplo para permitir solo web→API:
  - gcloud compute firewall-rules create allow-web-to-api –network=prod-vpc –direction=INGRESS –action=ALLOW –rules=tcp:8443 –source-tags=web –target-tags=api
- Use Private Service Connect y el acceso privado a Google para la comunicación de servicio a servicio sin salida a la red pública (egress); segmente con VPC Service Controls cuando sea apropiado.
- DNS híbrido: use Cloud DNS con políticas de reenvío y de entrada/salida para resolver nombres tanto on-premise como en la nube.
Integración on-premise y latencia
- Mantenga el estado cerca del cómputo o viceversa; si la base de datos on-premise debe seguir siendo la autoritativa, considere App Engine flexible o Compute Engine con Cloud VPN/Interconnect para el acceso privado.
- Introduzca cachés y colas para desacoplar las rutas síncronas y absorber las fluctuaciones de latencia (jitter); mida la latencia p95/p99, no solo los promedios.

Modos de fallo comunes: superposición de CIDR que bloquean rutas, redundancia insuficiente de la sesión BGP, fugas de DNS público o de salida (egress) que exponen servicios privados, y protocolos muy comunicativos (chatty) no previstos que sufren en enlaces de alta latencia.

Modernización, modelo operativo y optimización

Patrones de modernización de sistemas heredados
- Patrón Strangler Fig: colocar una fachada de API frente al monolito y enrutar dominios de forma incremental a nuevos servicios.
- Contenerización: estandarizar las imágenes base (preferir imágenes ligeras como Alpine cuando sean compatibles), ordenar las capas del Dockerfile para almacenar en caché la instalación de dependencias antes de copiar el código fuente para reducir el tiempo de compilación, y adoptar un pipeline de CI/CD con pruebas automatizadas en el entorno de staging.
- Datos gestionados: mover los almacenes de datos operativos a bases de datos gestionadas; elegir por dominio: Cloud SQL para cargas transaccionales, Bigtable para series temporales, Spanner para cargas de trabajo globalmente consistentes.
Validación de compatibilidad, consistencia y rendimiento de la aplicación
- Confirmar la compatibilidad del SO y del middleware, los límites de hilos y conexiones, y la semántica del sistema de archivos. Validar la portabilidad de las licencias y la medición del uso.
- Definir los requisitos de consistencia de los datos (lectura de tus propias escrituras, lecturas monotónicas, consistencia eventual vs. fuerte). Alinearlos con las bases de datos de destino y los patrones de acceso.
- Validar el rendimiento con pruebas de carga y recorridos de usuario sintéticos; asegurar que los presupuestos de SLO sean alcanzables después de la migración.
Observabilidad y cumplimiento
- Instrumentar las aplicaciones con Cloud Logging, Monitoring y Trace para localizar la latencia entre microservicios.
- Exportar los registros de auditoría y los cambios en las políticas de IAM a BigQuery y compartirlos con los auditores mediante vistas e IAM en los conjuntos de datos. Exportar métricas a largo plazo a Cloud Storage para cumplir con los requisitos de retención de varios años.
Modelo operativo y propiedad
- Adoptar prácticas de SRE: SLO, presupuestos de errores, respuesta a incidentes y postmortems sin culpa. Definir la propiedad del servicio, los runbooks y las rotaciones de guardia (on-call).
- Usar IaC (p. ej., Terraform) para aprovisionar la infraestructura de forma consistente. Tener en cuenta que Deployment Manager es específico de Google, puede limitar la automatización de recursos multinube y no es familiar para muchos ingenieros.
- Automatizar la consistencia de las políticas con Organization Policy, IAM Conditions, Config Sync y Policy Controller (OPA Gatekeeper) entre proyectos y entornos.
Estrategia multinube y contrapartidas del ’lock-in'
- Aumentar la portabilidad con Kubernetes, prácticas de 12-factor app, contratos definidos por OpenAPI y abstracciones de egreso de datos. Equilibrar la portabilidad con la carga operativa y el rendimiento; los servicios gestionados reducen el trabajo pesado pero pueden aumentar el costo de cambio.
Optimización de costos y rendimiento; desmantelamiento
- Escalar Compute Engine sin estado con grupos de instancias gestionados y autoescalado; elegir serverless (Cloud Functions o Cloud Run) para cargas de trabajo con picos o de MVP que se benefician de la escalabilidad a cero.
- Dimensionar correctamente las VM, habilitar el autoescalado en GKE, aplicar descuentos por uso comprometido y desmantelar los artefactos no utilizados. Hacer seguimiento de la realización de beneficios a través de KPI (disponibilidad, latencia, costo por servicio).
- Desmantelar los sistemas on-premise después de un período de enfriamiento y la confirmación de dependencias. Archivar o eliminar datos según la política de retención y actualizar la CMDB.

Escenario de problema práctico

Acme Weather Networks debe migrar su plataforma de sensores en tiempo real y una UI de administración J2EE heredada desde un centro de datos on-premise a Google Cloud. El sistema ingiere datos de 50,000 sensores que envían 10 lecturas por segundo y almacena cinco años de datos históricos (75 TB). Debe mantener el acceso privado al ERP y a Active Directory on-premise durante la transición, minimizar el tiempo de inactividad para una base de datos MySQL on-premise y eliminar las fallas de replicación intermitentes observadas a través de la VPN.

Establecer una zona de aterrizaje (landing zone) segura
- Crear la organización, las carpetas y los proyectos de prod/non-prod. Configurar una Shared VPC con rangos de IP que no se superpongan para asegurar la alcanzabilidad on-premise a través de la conectividad híbrida. Aplicar políticas de organización y exportaciones centralizadas de registros de auditoría a BigQuery con acceso de privilegio mínimo.
- Justificación: Prevenir conflictos de enrutamiento y aplicar una gobernanza base antes de que lleguen las cargas de trabajo.
Implementar identidad híbrida
- Configurar Google Cloud Directory Sync para replicar las identidades y grupos de AD y configurar SSO con SAML. Usar cuentas de servicio y roles personalizados de IAM para la plataforma y las cargas de trabajo.
- Justificación: Mantiene la identidad corporativa como la fuente de verdad y habilita el control de acceso de privilegio mínimo.
Aprovisionar conectividad y planificar para el rendimiento
- Comenzar con HA Cloud VPN para desarrollo y pruebas. Para la replicación de la base de datos de producción y la ingesta constante de sensores, aprovisionar Dedicated Interconnect con adjuntos de VLAN duales y sesiones BGP.
- Justificación: Interconnect proporciona una latencia más baja y menos caídas de paquetes que la VPN, estabilizando la replicación de MySQL y la ingesta por streaming.
Mover los datos históricos de manera eficiente
- Solicitar Transfer Appliances, cargar el conjunto de datos de 75 TB on-premise, enviarlo y rehidratarlo en Cloud Storage. Usar Storage Transfer Service para actualizaciones incrementales continuas si es necesario. Ejecutar Cloud DLP en los registros de soporte para desidentificar la PII antes de almacenarla en Bigtable o BigQuery.
- Justificación: La transferencia masiva sin conexión reduce el riesgo de la ventana de transición (cutover) y evita saturar los circuitos.
Realojar (rehost) la UI de administración J2EE
- Usar Migrate to Virtual Machines para hacer un ’lift-and-shift’ de la VM J2EE a Compute Engine. Colocar las instancias en un grupo de instancias gestionado detrás de un balanceador de carga HTTP(S). Aplicar reglas de firewall por etiquetas para forzar únicamente los flujos web→API→BD. Ejemplo:
  - gcloud compute firewall-rules create allow-web-to-api –network=prod-vpc –direction=INGRESS –action=ALLOW –rules=tcp:8443 –source-tags=web –target-tags=api
- Justificación: Reducción rápida del riesgo con un entorno de ejecución familiar, al tiempo que se aplican rutas de red de privilegio mínimo.
Migrar MySQL a Cloud SQL con tiempo de inactividad mínimo
- Establecer una línea base de rendimiento y habilitar el registro binario en el origen. Usar Database Migration Service para configurar la replicación continua en Cloud SQL. Habilitar el aumento automático del almacenamiento y crear alertas para la CPU cerca del 75% y un retraso de replicación (replication lag) inferior a 60 segundos.
- Justificación: La migración en línea logra un bajo tiempo de inactividad; el SQL gestionado reduce el trabajo pesado y hace cumplir los SLO operativos.
Ejecutar una transición (cutover) controlada
- Bajar los TTL del DNS 48 horas antes, congelar los cambios de esquema y programar una ventana de mantenimiento. Detener las escrituras on-premise, asegurar que el lag de DMS sea cero, ejecutar checksums y pruebas de humo (smoke tests) de la aplicación, y luego apuntar los clientes a Cloud SQL. Mantener un plan de reversión (rollback) donde las escrituras puedan ser redirigidas de nuevo al sistema on-premise si la validación falla.
- Justificación: Los pasos deterministas limitan el RTO y mantienen la consistencia de los datos.
Construir la ingesta para la telemetría en tiempo real
- Ingerir a través de Pub/Sub, procesar con Dataflow y almacenar las series temporales en Bigtable para escrituras y lecturas de baja latencia. Mantener la integración con el ERP privada a través de Interconnect.
- Justificación: Bigtable se ajusta al perfil de series temporales de alto rendimiento, y Pub/Sub desacopla a los productores con picos de actividad de los consumidores.
Contenerizar servicios e introducir CI/CD
- Contenerizar los servicios sin estado para GKE. Optimizar los Dockerfiles usando imágenes base ligeras y ordenando las capas para que la instalación de dependencias preceda a la copia del código fuente. Implementar un pipeline de CI/CD con pruebas automatizadas en staging y despliegues canary. Actualizar con tiempo de inactividad mínimo:
  - kubectl set image deployment/ingester ingester=gcr.io/acme/ingester:v2
- Justificación: Mejora la velocidad de despliegue, la fiabilidad y la escalabilidad sin una reescritura completa (big-bang).
Mejorar la observabilidad y la auditoría
- Instrumentar con Cloud Logging, Monitoring y Trace para identificar la latencia entre microservicios. Exportar los registros de auditoría a BigQuery y compartir vistas con alcance de auditor. Exportar métricas a largo plazo a Cloud Storage para cumplir con la retención de cinco años.
- Justificación: La telemetría de fidelidad total respalda los SLO y el cumplimiento.
Optimizar y desmantelar
- Habilitar el autoescalado en los MIG y GKE, dimensionar correctamente las instancias, aplicar descuentos por uso comprometido y programar cargas de trabajo que no son 24x7 en serverless (p. ej., Cloud Functions para tareas auxiliares) para escalar a cero. Después de alcanzar la estabilidad y tras un período de enfriamiento, desmantelar los sistemas on-premise, actualizar la CMDB y publicar los beneficios obtenidos.
- Justificación: Capturar eficiencias operativas y de costos mientras se eliminan los gastos de ejecución dual.
Operacionalizar y capacitar
- Finalizar los runbooks, la matriz RACI, las rotaciones de guardia (on-call) y los presupuestos de SLO/errores. Proporcionar planes de capacitación y certificación específicos para cerrar las brechas de habilidades. Preferir Terraform para IaC; tener en cuenta que Deployment Manager es específico de Google y podría no gestionar recursos que no sean de Google.
- Justificación: Un modelo operativo maduro sostiene la fiabilidad y la velocidad más allá del evento de migración.