CDL

Deep Dive

Practicar ahora
D4 · Modernización de infraestructura y aplicaciones

Migración y modernización a Google Cloud

Las 6 Rs de la migración, herramientas de Google Cloud para migrar workloads, y el camino de modernización de aplicaciones.

Las 6 Rs de la migración cloud

Cuando una empresa mueve workloads a la nube, elige una estrategia de migración. Las "6 Rs" son el framework estándar de la industria para categorizar estas estrategias.

Rehost"Lift and shift"

Mueve la app tal como está a la nube sin modificaciones. VM on-premises → Compute Engine. Sin optimización, máxima velocidad de migración.

Cuándo aplicar

Migrar rápidamente para salir de un datacenter. Primer paso antes de modernizar.

Replatform"Lift and optimize"

Pequeños cambios para aprovechar capacidades cloud sin rediseñar. Ej: migrar de MySQL en VMs a Cloud SQL.

Cuándo aplicar

Quieres beneficios cloud básicos (managed service, backups automáticos) con mínimo esfuerzo.

Repurchase"Drop and shop"

Cambia a un producto SaaS diferente. Ej: pasar de un CRM propio a Salesforce, o de Exchange a Google Workspace.

Cuándo aplicar

La app no es diferenciadora del negocio y existe un SaaS que cubre el caso de uso.

Refactor"Re-architect"

Rediseñar la app para usar capacidades cloud nativas: microservicios, contenedores, serverless. Mayor esfuerzo, mayor beneficio a largo plazo.

Cuándo aplicar

La app tiene problemas de escala o agilidad que solo se resuelven con rediseño.

Retire

Eliminar apps que ya no son necesarias. Típicamente 10-20% del portafolio en migraciones grandes puede retirarse.

Cuándo aplicar

La app está duplicada, no tiene usuarios activos, o el negocio ya no la necesita.

Retain"Revisit later"

Mantener la app on-premises por ahora por razones técnicas, contractuales o de negocio. No todo debe migrarse el día 1.

Cuándo aplicar

App con contrato largo vigente, regulaciones específicas, o migración no rentable aún.

Herramientas de migración en Google Cloud

HerramientaQué migraDetalles clave
Migrate to Virtual MachinesVMs de VMware, AWS, Azure, o bare metal → Compute EngineReplicación continua + corte mínimo. Prueba la VM en GCP antes del corte definitivo.
Database Migration ServiceBases de datos relacionales a Cloud SQL o AlloyDBPostgreSQL, MySQL, SQL Server. CDC (Change Data Capture) para migración con mínimo downtime.
DatastreamCambios de BD en tiempo real (replicación continua)CDC serverless. Replica de Oracle, MySQL, PostgreSQL a BigQuery, Cloud Storage, Spanner.
Storage Transfer ServiceDatos de AWS S3, Azure Blob, HDFS, on-premises → Cloud StorageTransferencias programadas o continuas. Para petabytes de datos.
Transfer ApplianceDatos masivos on-premises (>20TB) → Cloud StorageDispositivo físico que Google envía. Copias datos offline y lo devuelves a Google.
BigQuery Data Transfer ServiceDatos de SaaS (Google Ads, YouTube, Salesforce) → BigQueryConectores nativos para decenas de fuentes de datos externas.

Modernización: de VMs a cloud-native

1. Assess

Inventariar y evaluar apps actuales. ¿Qué migrar, modernizar, retirar? Google Cloud Rapid Assessment & Migration Program (RAMP) ayuda con este análisis.

2. Migrate (Rehost)

Lift-and-shift: mueve VMs tal como están a Compute Engine. Rápido, sin cambios de código. Base para modernización posterior.

3. Modernize (Replatform)

Conteneriza apps con Docker, despliega en GKE o Cloud Run. Migra bases de datos a servicios gestionados (Cloud SQL, Spanner). Adopta servicios gestionados.

4. Cloud-native (Refactor)

Rediseña como microservicios, usa Cloud Functions para lógica event-driven, Pub/Sub para mensajería, y APIs gestionadas. Máximo aprovechamiento de GCP.

GKE Enterprise: híbrido y multi-cloud

GKE Enterprise (anteriormente Anthos) es la plataforma de Google para gestionar aplicaciones en múltiples entornos: GCP, on-premises, AWS y Azure. Basado en GKE, permite un plano de control unificado para Kubernetes en cualquier lugar.

GKE clusters

Kubernetes gestionado on-premises o en otras nubes. Mismo API de GKE en todos los entornos.

Config Management

Policy-as-code: aplica configuraciones y políticas de seguridad en todos los clusters desde un repositorio Git.

Cloud Service Mesh

Istio gestionado para service mesh: tráfico, observabilidad, seguridad (mTLS) entre microservicios.

Caso de uso

Empresas con regulaciones que requieren on-premises, o estrategia multi-cloud sin vendor lock-in.

Nube híbrida y multi-cloud

Nube híbrida (Hybrid Cloud)

Combinación de infraestructura on-premises con una o más nubes públicas, trabajando juntas. Las empresas mantienen algunos workloads on-premises y otros en la nube.

Razón regulatoria: datos sensibles deben permanecer on-premises
Inversión existente: hardware reciente con vida útil restante
Latencia: procesamiento near-real-time que no puede tolerar la red
Migración gradual: transición paso a paso sin big bang

Multi-cloud

Usar servicios de múltiples proveedores de nube (GCP + AWS + Azure) deliberadamente. No confundir con tener presencia en dos nubes por accidente.

Evitar vendor lock-in: no depender de un solo proveedor
Best-of-breed: usar el mejor servicio de cada nube para cada caso
Redundancia: failover entre proveedores para máxima disponibilidad
Acquisiciones: empresas adquiridas ya están en otra nube

GKE Enterprise: un panel de control para todo

GKE Enterprise (anteriormente Anthos) permite gestionar apps en múltiples entornos (GCP, on-premises, AWS, Azure) desde un único panel de control basado en Kubernetes. Config Management aplica políticas de seguridad consistentes en todos los clusters. Cloud Service Mesh (Istio) gestiona la comunicación entre microservicios en cualquier entorno.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una empresa tiene 200 VMs en su datacenter on-premises ejecutando aplicaciones legacy críticas. Quieren migrar a Google Cloud lo más rápido posible para salir del datacenter en 6 meses. Las apps no pueden ser modificadas. ¿Qué estrategia y herramienta deben usar?