Elegir dónde desplegar una aplicación ya no se limita a un solo proveedor de nube. Comprender las estrategias de multinube y cómo se conectan con el concepto de lock-in es fundamental para tomar decisiones técnicas y de negocio que protejan la flexibilidad de tus proyectos. A continuación se explican las principales formas de adoptar multinube, sus ventajas y los retos que cada una implica.
¿Qué significa realmente multinube?
Se habla de multinube cuando utilizas más de un proveedor de servicios de nube pública para una misma aplicación, sistema o plataforma [0:20]. Por ejemplo, una aplicación cuyo backend corre en AWS mientras ciertos servicios operan en Google Cloud. También aplica cuando una empresa despliega unas cargas de trabajo en Azure y otras en AWS. Lo clave es que más de un proveedor participa en la operación de un mismo producto.
Una vez claro el concepto, lo importante es entender que no existe una única forma de implementar multinube. Hay al menos cinco estrategias diferenciadas, y cada una trae consigo implicaciones de costos, complejidad técnica y distintos tipos de lock-in.
¿Cuándo la decisión de nube es arbitraria?
La primera estrategia es la arbitraria [1:08]. Ocurre cuando alguien con poder de decisión —el dueño del producto, por ejemplo— elige un proveedor sin un criterio estrictamente técnico. Puede deberse a un convenio comercial, a un contrato vigente con un cloud provider o simplemente a que el equipo ya domina esa plataforma. Es una decisión válida y frecuente: "ya tenemos un contrato con Oracle a tres años, no podemos movernos" [2:10]. Aunque no nace de un análisis técnico profundo, condiciona la arquitectura y puede generar dependencia.
¿Por qué elegir lo mejor de cada proveedor de nube?
La estrategia de elección consiste en seleccionar lo mejor de cada mundo tras evaluar pros y contras de cada cloud provider [2:36]. Un caso real muy común: el backend corre en Amazon (Kubernetes en EKS), pero todo el flujo de CI/CD se gestiona con Azure DevOps [2:55]. Así se aprovechan las fortalezas de dos nubes distintas.
Esta estrategia tiene dos retos claros:
- Puede generar vendor lock-in: migrar Azure DevOps al servicio nativo de AWS implica reconstruir prácticamente todo el pipeline [3:16].
- Requiere que las personas del equipo dominen dos nubes, lo cual es un desafío técnico y de capacitación importante [3:30].
La recomendación es siempre buscar lo que mejor se acomode a tu caso de uso sin sesgarte hacia un solo proveedor.
¿Qué implica una estrategia agnóstica basada en open source?
La estrategia agnóstica apuesta por tecnologías de código abierto para lograr portabilidad [3:55]. Si despliegas Platzi Wallet en Kubernetes sobre AWS, puedes replicar ese clúster en Azure, Google Cloud o incluso on-premise, porque todo está basado en open source [4:15]. Aquí no piensas tanto en el proveedor, sino en que los servicios que componen la aplicación estén disponibles en cualquier nube.
El limitante es el product lock-in: dependes de productos específicos de código abierto y de sus ecosistemas [4:35].
¿Qué tan viable es la multinube paralela como disaster recovery?
La estrategia paralela es la más solicitada por los clientes [4:45]: "si Amazon se cae, que automáticamente entre Azure y todo siga operando". Suena ideal, pero la realidad es distinta. Los retos técnicos, el costo de infraestructura y el esfuerzo de desarrollo son enormes [5:10]. Funciona como un esquema de disaster recovery, y para implementarlo correctamente las empresas deben definir dos métricas críticas:
- RTO (Recovery Time Objective): el tiempo máximo aceptable para restaurar el servicio.
- RPO (Recovery Point Objective): la cantidad máxima de datos que se puede perder medida en tiempo [5:30].
Este modelo exige profesionales con conocimiento profundo en al menos dos nubes, lo que eleva la complejidad organizacional.
¿Cómo funciona la multinube segmentada por cargas de trabajo?
La estrategia segmentada divide las cargas de trabajo por criterio funcional [5:55]. Por ejemplo, todo el backend en Azure y toda la capa de data, analítica y machine learning en Google Cloud Platform. Cada equipo se especializa en su nube, lo cual genera un skills lock-in: el equipo de datos domina GCP mientras el de backend domina Azure [6:15].
Es una opción válida que permite aprovechar las fortalezas de cada proveedor en áreas específicas, siempre y cuando se asuma el costo de mantener conocimiento distribuido.
Lo más valioso al evaluar estas estrategias es contar con el criterio para decidir: ¿una nube o varias? ¿Qué retos asumo? ¿Qué tipo de lock-in estoy dispuesto a aceptar? Conocer el abanico de opciones te da la capacidad de tomar decisiones informadas para cada aplicación. Si ya has enfrentado alguna de estas decisiones, comparte tu experiencia y cuéntanos qué estrategia funcionó mejor en tu caso.
