Siguiendo la captura anterior, tu inversión en los nodos de GCVE queda protegida durante todo el ciclo. Si en el segundo año decidís migrar una carga de VMware hacia Compute Engine (GCE) o GKE, podés cancelar el CUD de GCVE y transferir su valor remanente para establecer un nuevo CUD equivalente en GCE o GKE.

Esto te permite mantener el descuento, conservar el ahorro y acompañar la evolución de tus workloads, reflejando de manera precisa el enfoque de Lift, Run & Transform.

Conectividad Nativa: El Primer Paso hacia PaaS

Como mencioné antes, uno de los errores más comunes es ver GCVE como un silo. Su verdadero valor está en su conectividad nativa de baja latencia con el ecosistema de Google Cloud. Una vez que tu entorno VMware está en GCVE, tus aplicaciones heredadas están literalmente a milímetros de consumir servicios nativos de Google. 

No aprovechar estos servicios nativos representa una pérdida del TCO real de la infraestructura. Por eso es fundamental utilizar el tiempo que GCVE ofrece para ser estratégicos con cada aplicación y planificar qué workloads pueden modernizarse sin disrupción.

Desde Wetcom hacemos especial foco en identificar el consumo base para dimensionar Flex CUDs con precisión, asegurando ahorro en todo el cómputo y habilitando una transición ordenada hacia otros servicios cuando tenga sentido. 

Algunos ejemplos de caminos posibles y que podemos probar con PoCs sin disrupción incluyen:

• Hacia Google Compute Engine (GCE):  Ideal para workloads que pueden beneficiarse de familias de máquinas especializadas, incluidas instancias con GPU o TPU.
• Hacia servicios PaaS de Bases de Datos: Como Cloud SQL, AlloyDB o Cloud Spanner. Muchas de estas transiciones se logran de manera transparente utilizando el servicio nativo Database Migration Service (DMS) para migraciones homogéneas. Esto libera la carga operativa de los DBAs delegando la responsabilidad a Google.
  Un dato de valor, la posibilidad de probar bases de datos como las que mencione y sin disrupción es un gran beneficio, ya que al tener baja latencia entre GCVE y el servicio nativo, las pruebas de concepto no impactan el servicio de producción.
• Hacia Contenedores (Cloud Run / GKE):  GCVE facilita identificar qué VMs son candidatas naturales para avanzar hacia modelos cloud-native cuando llegue el momento.

Seguridad Nativa y Mitigación de Riesgos

Y no nos limitemos únicamente en la modernización de nuestras aplicaciones.  La preocupación por la seguridad en la nube es natural, y en Google Cloud se aborda con un enfoque de “menor privilegio” y “guardrails” claros.

• La interconexión de GCVE con el VPC del cliente permite configurar micro-firewalls granulares, garantizando que solo los puertos y servicios estrictamente necesarios estén abiertos.
• Servicios como Cloud Armor, Next Generation Firewall (NGFW) y Security Command Center (SCC) ofrecen una batería de protección y análisis. SCC, en particular, analiza la infraestructura y alerta sobre riesgos, ofreciendo una guía de best practices para mitigar vulnerabilidades como ataques de ransomware.
• Y algo fundamental: establecer un Foundation adecuado desde el inicio, definiendo límites, permisos y controles por perfil de usuario, para evitar configuraciones riesgosas o costos inesperados. (Desde Wetcom podemos acompañarlos en este diseño.)

Pero mejor, veamos esta gráfica que resume claramente el recorrido que estamos describiendo:

Esta gráfica de Google Cloud resume la hoja de ruta que podemos diseñar, mostrando cómo se pasa de un costo base del 100% on-premise a aproximadamente un 45% del costo original en el quinto año. Lo interesante es que este ahorro puede sostenerse —y amplificarse— gracias a los Flex CUDs, que permiten transicionar el compromiso a distintos servicios de cómputo a medida que avanzamos con el Replatform & Refactor hacia servicios como GCE o GKE. Esto habilita liberar nodos de GCVE y reducir, de forma progresiva, parte del licenciamiento de VMware que quedaría en desuso.

El resultado final es un entorno híbrido optimizado:

• GCVE para aquellas aplicaciones legacy que necesitan seguir ejecutándose allí, a milímetros de los servicios nativos de Google.
• Y el resto de las aplicaciones ya modernizadas sobre GCE, GKE o bases de datos como servicio, aprovechando todo el potencial de la nube.

El proceso puede requerir tiempo para determinadas cargas de trabajo, pero el impacto acumulado habilita un aprovechamiento total del TCO de tu infraestructura con el correr de los años.

Inversión Inteligente, Futuro Asegurado

La elección de GCVE no es un compromiso con la tecnología de ayer, sino una decisión inteligente de migración. Te permite resolver la urgencia del presente mientras habilitás el futuro de la modernización, con la flexibilidad financiera que ofrecen los Flex CUDs.

Y si te quedaste con ganas de indagar un poco más sobre hacia dónde podrías transicionar tus cargas de trabajo en GCP, te recomiendo este episodio de nuestro #InsanePodcast, donde contamos distintos escenarios posibles:Google Cloud VMware Engine: Cómo evitar la fatiga tecnológica