Elegir una estrategia multinube define cómo tu aplicación se distribuye entre proveedores como AWS, Azure, Google Cloud u Oracle. Aquí entenderás qué significa multinube, qué estrategias existen y cómo decidir cuál se ajusta a tu caso, sin caer en decisiones impulsivas ni en costos técnicos imposibles de sostener.

Qué significa multinube y cuándo se aplica

Hablamos de multinube cuando usas más de un proveedor de servicios de nube pública para una misma aplicación, sistema o plataforma. No es un concepto teórico: pasa todos los días en empresas reales.

Un ejemplo claro es Platzi Wallet corriendo en AWS y, al mismo tiempo, consumiendo servicios de Google Cloud. Ahí ya tienes dos nubes trabajando para una sola aplicación. Otras compañías despliegan cargas de trabajo distintas en Azure y AWS, y eso también cuenta como multinube [00:30].

¿Qué es multinube? Es el uso de dos o más proveedores de nube pública para soportar una aplicación o varias cargas de trabajo dentro de la misma organización.

Cuáles son las estrategias de multinube que debes conocer

No todas las decisiones multinube se toman por criterios técnicos. Algunas nacen de contratos, otras de habilidades del equipo y otras de un análisis serio de pros y contras.

Estrategia arbitraria y por elección

La estrategia arbitraria suena rara, pero ocurre seguido. El dueño de Platzi Wallet llega y dice: "quiero que corra en Azure". Punto. Puede venir de un convenio firmado con el proveedor, de un contrato a tres años con Oracle, o simplemente porque todo el equipo ya domina esa nube [01:30].

La estrategia de elección es la más recomendada. Estudias los proveedores, comparas, y eliges lo mejor de cada uno según tu caso de uso. Un caso real: el backend corre en Amazon usando Kubernetes, pero el CI/CD vive en Azure DevOps [03:10]. Tomas lo mejor de los dos mundos.

Las ventajas y desventajas de elegir esta vía:

• Aprovechas las fortalezas específicas de cada proveedor.
• Puedes generar cierto vendor lock-in en herramientas como Azure DevOps.
• Tu equipo necesita dominar dos nubes, lo que sube la exigencia técnica.

Estrategia agnóstica y segmentada

La estrategia agnóstica se apoya en open source. Despliegas Platzi Wallet sobre Kubernetes en AWS y replicas el clúster en Azure, Google Cloud o incluso on-premise. Como todo está basado en tecnologías abiertas, mover la carga es directo. El límite aquí aparece como product lock-in, atado a productos específicos de open source [04:50].

La estrategia segmentada divide cargas por tipo. Por ejemplo, todo el backend en Azure y toda la analítica de datos y machine learning en Google Cloud Platform [06:50]. Es válida y muy común, pero genera skills locking: el equipo de datos solo sabe GCP y el de backend solo sabe Azure.

¿Cuál es la mejor estrategia multinube? Depende de tu caso de uso. La estrategia de elección suele ganar porque combina lo mejor de cada proveedor sin sesgos arbitrarios.

Por qué la estrategia paralela es la más pedida y la más compleja

Es el sueño de todo cliente: "si AWS se cae, que entre Azure automáticamente y todo siga operando". Suena maravilloso, pero los retos técnicos y los costos son enormes [05:50].

Esta estrategia funciona como un esquema de disaster recovery. Si una nube falla, otra toma el relevo. Para que tenga sentido, debes definir dos métricas críticas:

• RTO (Recovery Time Objective): cuánto tiempo puedes estar caído.
• RPO (Recovery Point Objective): cuántos datos puedes permitirte perder.

No olvides estos dos términos. Aparecen en cualquier conversación seria sobre continuidad y recuperación. Además, el esquema paralelo exige personas con conocimiento profundo en dos nubes simultáneamente, lo que multiplica el costo de talento.

¿Qué son RTO y RPO en multinube? RTO es el tiempo máximo aceptable de inactividad y RPO es la cantidad máxima de datos que puedes perder en un incidente. Ambos definen si una estrategia paralela es viable.

Cómo elegir tu estrategia multinube según el caso de uso

Lo importante no es escoger la nube de moda, sino tener el criterio para evaluar el abanico completo. Cuando definas dónde corre tu aplicación, contesta tres preguntas: ¿por qué multinube?, ¿qué retos asumo?, ¿qué pros y contras tiene cada estrategia?

Un resumen de las estrategias revisadas:

• Arbitraria: decisión del negocio o del owner, sin criterio técnico.
• Elección: lo mejor de cada nube según el caso de uso.
• Agnóstica: todo en open source para máxima portabilidad.
• Paralela: redundancia entre nubes con altísima complejidad.
• Segmentada: cargas distintas en proveedores distintos.

Mi recomendación sigue siendo la de elección: nunca te sesgues a que todo debe correr en una sola nube porque sí. Busca lo mejor de los mundos en función de tu aplicación y de tu equipo.

¿Cuál de estas estrategias se parece más a lo que ya estás aplicando en tu proyecto? Cuéntalo en los comentarios.