Multicloud frente a nube única: una opinión honesta

«Multicloud» es una de esas expresiones que suenan a madurez. Aparece en las presentaciones a los consejos de administración y en los argumentarios de los proveedores como prueba de que una empresa se toma en serio la resiliencia y el poder de negociación. En la práctica, la decisión es mucho menos glamurosa y mucho más trascendente. Elige mal y o bien te encierras en un callejón sin salida, o ahogas a un equipo pequeño en una complejidad que nunca tuvo el personal para sostener.

Construimos y operamos infraestructura en la nube para clientes de tamaños y perfiles de riesgo muy distintos, y la respuesta honesta es que ninguna de las dos estrategias es correcta de forma universal. Este artículo recorre lo que cada enfoque te aporta de verdad, dónde se esconden los costes y cómo tomar la decisión según tu situación en lugar de según la diapositiva que alguien te enseñó.

Qué quiere decir la gente en realidad con «multicloud»

Antes de que el debate tenga sentido, hay que separar tres cosas muy distintas que se agrupan bajo una sola palabra.

• El multicloud verdadero consiste en ejecutar las mismas cargas de trabajo, o cargas comparables, en dos o más proveedores (por ejemplo AWS y Google Cloud) de forma deliberada, a menudo con la capacidad de desviar el tráfico entre ellos.
• La nube híbrida mezcla un proveedor público con infraestructura local (on-premise) o privada. Habitual en sectores regulados y en empresas con centros de datos ya existentes.
• El multicloud accidental es lo que la mayoría de los equipos tiene en realidad: la plataforma principal es AWS, pero marketing levantó algo en Azure, al equipo de datos le gusta BigQuery y un producto adquirido todavía corre en DigitalOcean. Nadie eligió esto. Se fue acumulando.

Esa tercera categoría importa, porque muchas afirmaciones del tipo «somos multicloud» significan en realidad «perdimos el control». Ser lúcido sobre en cuál de estas situaciones estás es el primer paso honesto. Una estrategia hacia la que derivaste no es una estrategia.

Los argumentos a favor de una nube única

Para la mayoría de las empresas por debajo de cierta escala, comprometerse con un solo proveedor es la opción pragmática ganadora, y conviene dejar claro por qué.

La simplicidad operativa es una virtud, no un compromiso. Un único modelo de identidad y acceso. Un único modelo mental de red. Una única consola de facturación. Un único conjunto de herramientas que tus ingenieros de verdad dominan a fondo. Cada proveedor tiene sus propias peculiaridades en cómo se comportan las VPC, el IAM, los balanceadores de carga y las bases de datos gestionadas, y dominar uno ya es bastante difícil. Pedir a un equipo de plataforma de cinco personas que sea fluido en dos es la receta para que los incidentes se alarguen y las alertas de las dos de la madrugada den más miedo.

Descuentos más profundos. Los compromisos de uso, las instancias reservadas y los planes de ahorro premian la concentración. Cuando repartes el gasto entre proveedores, debilitas tu posición negociadora con cada uno y a menudo no alcanzas los umbrales de volumen que desbloquean los mejores precios. La consolidación es una de las palancas en las que nos apoyamos en nuestra guía de optimización de costes en la nube, y el multicloud puede trabajar en su contra de forma silenciosa.

Servicios gestionados que de otro modo tendrías que reconstruir. El verdadero valor de una nube moderna no es la capacidad de cómputo en bruto, es la capa gestionada: bases de datos serverless, streaming de eventos, colas, identidad, herramientas de ML. Ahí es donde los proveedores se diferencian, y esos servicios casi nunca son portables. En el momento en que te comprometes a mantenerte neutral respecto al proveedor, te cierras el acceso a los mismísimos servicios que permitirían a un equipo pequeño avanzar rápido.

El compromiso que aceptas es el riesgo de concentración. Si tu único proveedor tiene un mal día, tú también. Para una amplia parte de los negocios, ese riesgo es menor y más barato de mitigar que el impuesto permanente de operar en todas partes.

Los argumentos a favor del multicloud

El multicloud no está equivocado. Solo es caro, y necesita una razón de verdad. Estas son las razones que lo justifican de forma genuina.

Requisitos regulatorios y de residencia de datos. Algunas jurisdicciones o contratos exigen que los datos residan en regiones concretas o bajo proveedores concretos, y puede que ningún proveedor único satisfaga todas las restricciones que arrastras. Este es uno de los motores más legítimos, sobre todo para empresas que sirven a clientes del sector público europeo o que operan bajo regímenes estrictos de soberanía de datos.

Riesgo de proveedor real a gran escala. Para una empresa cuyos ingresos íntegros dependen de una disponibilidad permanente, un solo proveedor es un único punto de fallo que la dirección quizá no esté dispuesta a aceptar. A una escala suficiente, el coste de mantener un entorno secundario en caliente en otra nube es pequeño frente al coste de una caída de varias horas.

Capacidades best-of-breed. De vez en cuando un proveedor es notablemente mejor para una tarea concreta: una plataforma de ML particular, una base de datos especializada, un modelo de precios que encaja con una carga de trabajo a ráfagas. Usarlo deliberadamente para esa única carga, mientras tu núcleo permanece en otro sitio, es una forma razonable y acotada de multicloud.

Palanca de negociación. Poder moverte de verdad te da un mejor asiento en la mesa cuando se renuevan los contratos. La palabra clave es «de verdad». Una palanca que no puedes accionar realmente es un farol, y los proveedores suelen notarlo.

Fíjate en lo que falta en esta lista: la «resiliencia» como aspiración vaga, o «evitar el lock-in» como reflejo. Eso son sensaciones, no requisitos. El multicloud se gana su coste cuando puedes nombrar la restricción concreta que lo impulsa.

Los costes ocultos que nadie pone en la diapositiva

El argumentario del multicloud siempre habla de lo que ganas. La conversación honesta va de lo que exige. Según nuestra experiencia, los equipos subestiman de forma consistente cuatro cosas.

1. Carga cognitiva. Cada proveedor es todo un mundo de conceptos, valores por defecto y modos de fallo. Duplicar esa superficie no duplica el esfuerzo, lo hace más que duplicarse, porque ahora tu equipo también es dueño de las costuras entre ellos.
2. Red y egress. Mover datos entre nubes no es ni gratis ni rápido. La transferencia de datos entre nubes acumula tarifas de egress y añade latencia, y esos cargos se esconden dentro de las decisiones de arquitectura hasta que aparecen en la factura. Un servicio charlatán que abarca dos proveedores puede convertirse en silencio en una de tus mayores partidas de gasto.
3. La trampa del mínimo común denominador. Para seguir siendo portables, los equipos a menudo se niegan a usar los mejores servicios gestionados de cada proveedor y reconstruyen versiones genéricas por su cuenta. Acabas pagando por dos nubes mientras obtienes las capacidades avanzadas de ninguna, y tus ingenieros mantienen fontanería en lugar de entregar producto.
4. Superficie de seguridad. Dos nubes significan dos sistemas de identidad, dos conjuntos de políticas de red, dos registros de auditoría y el doble de posibilidades de configurar algo mal. Mantener una postura de seguridad coherente se vuelve mucho más difícil de imponer, que es exactamente por lo que una arquitectura zero-trust pasa a ser casi obligatoria, y no opcional, en cuanto abarcas varios proveedores.

Ninguno de estos es motivo para no ir nunca a multicloud. Son motivos para entrar con los ojos abiertos y con el personal adecuado.

Un camino intermedio: portable donde importa

El debate se plantea a menudo como todo o nada, pero la realidad pragmática en la que aterrizan la mayoría de los equipos maduros está en algún punto intermedio. Puedes reducir el lock-in en las capas donde la portabilidad es barata, sin dejar de usar servicios gestionados donde rinden.

• Empaqueta las cargas de trabajo en contenedores para que la capa de cómputo sea ampliamente portable.
• Usa infraestructura como código (Terraform o similar) para que los entornos sean reproducibles y no ensamblados a mano clic a clic.
• Mantén la lógica central de tu aplicación libre de dependencias fuertes con las peculiaridades propietarias de un solo proveedor, aun cuando uses con gusto la base de datos gestionada de ese proveedor.
• Abstrae las piezas verdaderamente críticas y difíciles de migrar (como el acceso al almacenamiento de objetos) tras una fina interfaz interna, de modo que una futura mudanza sea un proyecto y no una reescritura.

Esto te da la mayor parte del valor de seguro de la portabilidad sin pagar el impuesto operativo completo del multicloud. No eres neutral respecto al proveedor, eres flexible respecto al proveedor, y para la mayoría de las empresas ese es el punto óptimo.

Cómo decidir de verdad

Deja a un lado la ideología. Recorre estas preguntas con honestidad junto a tu equipo.

1. ¿Tenemos una restricción con nombre? ¿Una regulación concreta, una cláusula contractual o un requisito de disponibilidad que un solo proveedor no pueda cumplir? Si es así, el multicloud o el híbrido probablemente estén sobre la mesa. Si no, sigue adelante.
2. ¿Sabemos operar bien una nube hoy? Si tu equipo todavía está aprendiendo los fundamentos de un proveedor, añadir un segundo no añadirá resiliencia, añadirá caídas.
3. ¿Cuál es el coste real del riesgo de concentración para nosotros? Modela el impacto de negocio concreto de que tu proveedor principal tenga un mal día. Para muchas empresas es sobrevivible y más barato de asegurar con copias de seguridad y multirregión que con multicloud.
4. ¿Tenemos a las personas? El multicloud es un compromiso operativo, no una configuración de una sola vez. Si no puedes dotar de experiencia continua en cada plataforma, no empieces.
5. ¿Nuestro multicloud es accidental? Si ya estás repartido entre proveedores por accidente, decide de forma deliberada si consolidar o formalizar. Ir a la deriva es lo peor de ambos mundos.

Si respondes a esto con honestidad, la elección correcta suele volverse evidente. Las empresas que sufren son las que respondieron a la diapositiva de un proveedor en lugar de a sus propias preguntas.

Cómo puede ayudar Innovation T

La mayoría de los equipos no necesita una religión sobre la estrategia de nube. Necesita una evaluación lúcida de sus restricciones reales, de la capacidad de su equipo y de su factura. En Innovation T ayudamos a empresas en Túnez y más allá a tomar esta decisión sin el ruido: diseñando configuraciones single-cloud que se mantienen simples y económicas, diseñando entornos multicloud e híbridos deliberados allí donde la regulación o la escala realmente lo exigen, y desenredando la dispersión accidental dentro de la cual tantos equipos se despiertan.

Tanto si estás eligiendo un proveedor por primera vez, como si planeas una migración o intentas averiguar por qué tu infraestructura se siente más pesada de lo que debería, nuestro equipo de ingeniería en la nube puede ayudarte a decidir y luego a construirla como es debido. Explora nuestros servicios o ponte en contacto y empezaremos por tus restricciones, no por una plantilla.