Multi-cloud o single-cloud: cómo decidir sin dogmas

Pocas discusiones generan tanto humo como la de multi-cloud. Hay quien lo vende como obligatorio («no dependas de un proveedor») y quien lo descarta por completo («complejidad innecesaria»). Como casi siempre, la respuesta correcta es: depende. Este es el marco que uso para decidir.

Lo que el multi-cloud cuesta de verdad

  • Duplicidad de conocimiento: tu equipo tiene que dominar dos ecosistemas de IAM, redes, monitorización y facturación.
  • Mínimo común denominador: para ser portable renuncias a los servicios gestionados más potentes de cada nube.
  • Tooling doble: pipelines, Terraform providers, alertas y seguridad multiplicados por dos.

Cuándo sí tiene sentido

  • Requisitos regulatorios o de clientes que exigen residencia de datos o proveedor concreto.
  • Adquisiciones: heredas infraestructura en otra nube y migrarla no compensa.
  • Cargas muy específicas donde otra nube es claramente superior o más barata para ese caso.
  • Escala suficiente para negociar precios usando la alternativa como palanca real.

Mi recomendación práctica

Para la mayoría de equipos: una nube principal, bien gobernada, con IaC limpio y contenedores donde aporten. Esa disciplina —Terraform, Kubernetes, pipelines agnósticos— es la verdadera protección contra el vendor lock-in: no estar en dos nubes, sino poder moverte si algún día hace falta. Portabilidad como opción, no como impuesto diario.

Conclusión

No elijas arquitectura por miedo ni por moda. Elige por requisitos, coste total y capacidad real de tu equipo. El multi-cloud es una herramienta, no una religión.

¿En cuántas nubes opera tu equipo y por qué? Cuéntamelo en los comentarios. 😊