Nube híbrida y multi-nube

Dos problemas, dos soluciones distintas

Un banco regional mantiene su libro mayor central en un mainframe dentro de su propio centro de datos, porque mover 40 años de historial de transacciones y un rastro de auditoría que vigila un regulador estricto no es algo que se hace a la ligera. Pero el banco también quiere que su nueva app móvil corra en infraestructura capaz de absorber un pico de tráfico navideño sin comprar servidores que usa 3 días al año. Ese es un problema: conectar infraestructura que no puedes abandonar con infraestructura que quieres agregar.

Una empresa distinta, una app social en pleno crecimiento, ya se comprometió a un contrato multianual de miles de millones de dólares con un solo proveedor de nube, y ve cómo ese contrato único domina su presupuesto de infraestructura. Perder poder de negociación, y estar a una disputa contractual de una renegociación dolorosa, es un problema diferente: depender de un solo proveedor para todo.

Los modelos de despliegue de la lección anterior no tienen un nombre para ninguna de las 2 soluciones por sí solas. La nube híbrida y la multi-nube son lo que las organizaciones construyen cuando la nube pública, la privada y la comunitaria resuelven parte del problema cada una, pero ninguna lo resuelve completo por sí sola.

Nube híbrida: 2 infraestructuras unidas

NIST define la nube híbrida como "una composición de 2 o más infraestructuras de nube distintas (privada, comunitaria o pública) que se mantienen como entidades únicas, pero están unidas por tecnología estandarizada o propietaria que permite la portabilidad de datos y aplicaciones". Lee eso con cuidado: las piezas se mantienen separadas. El mainframe del banco no se convierte en parte de AWS, y AWS no se convierte en parte del centro de datos del banco. Lo que las conecta es una capa, construida específicamente para mover datos y cargas de trabajo entre las 2, que vuelve el límite entre ellas lo más invisible posible para quien las usa.

Esa capa de conexión es una categoría de producto real, y varios proveedores venden justo esto. AWS Outposts extiende el hardware, las APIs y los servicios de AWS hasta el propio centro de datos de una empresa, así que un equipo puede correr las mismas herramientas en sitio y en la nube pública sin aprender 2 plataformas distintas. Azure Arc y Azure Stack HCI de Microsoft hacen lo equivalente para Azure: administran servidores locales, clústeres de Kubernetes y bases de datos como si fueran recursos de Azure, sin importar dónde estén físicamente. En ambos casos, el punto es la portabilidad: mover una aplicación o un conjunto de datos a través del límite sin reconstruirla.

Vuelve al banco: el libro mayor se queda en el mainframe que no se puede mover, y la app móvil corre en la nube pública, donde puede absorber un pico de tráfico de la noche a la mañana. La nube híbrida es lo que deja que ambas mitades funcionen como un solo sistema en vez de 2 sin relación, compartiendo identidad, monitoreo y, en algunos casos, datos, a través del límite entre ellas.

Multi-nube: más de un proveedor público

La multi-nube significa algo más estrecho de lo que suena: usar servicios de nube pública de 2 o más proveedores separados, AWS y Google Cloud, por ejemplo, en vez de comprometerse por completo con uno solo. La propia definición de Google Cloud lo mantiene simple: una organización usa servicios de cómputo en la nube de al menos 2 proveedores públicos para correr sus aplicaciones.

La app social de la introducción es un patrón real, no un supuesto. Snap Inc, la empresa detrás de Snapchat, se comprometió a gastar al menos 2 mil millones de dólares con Google Cloud durante 5 años a partir de 2017, un contrato tan grande que la propia solicitud de oferta pública inicial de Snap lo nombró como un riesgo financiero importante. La respuesta de Snap fue agregar un segundo compromiso, separado: al menos mil millones de dólares con AWS para fines de 2021, para lo que su documento llamó "soporte de infraestructura redundante". Hoy la infraestructura de Snap corre como microservicios repartidos entre ambos proveedores, así que ni el precio, ni una interrupción, ni la renovación de contrato de un solo proveedor pueden dictar todos los términos.

El bloqueo de proveedor es el motivo principal por el que las organizaciones adoptan multi-nube, pero no el único. Algunos servicios son genuinamente más fuertes en un proveedor específico, así que un equipo podría correr su almacén de datos en una nube y su pipeline de aprendizaje automático en otra, para usar lo mejor de cada proveedor. Las leyes de residencia de datos en algunos países exigen que ciertos datos permanezcan dentro de las fronteras de ese país, y la región más rápida de un proveedor ahí no siempre es la que la empresa ya usa en todos lados.

El límite: híbrida o multi-nube, y por qué "ambas" es común

La nube híbrida y la multi-nube responden preguntas distintas, y un escenario normalmente solo pone a prueba una a la vez.

Una empresa puede ser las 2 cosas a la vez, y cada vez lo es más. Piensa otra vez en una red hospitalaria: los registros de pacientes se quedan en hardware privado y local por cumplimiento, la mitad híbrida, mientras su sistema de facturación corre en AWS y su servicio de telemedicina corre en un proveedor distinto elegido por menor latencia en ciertas regiones, la mitad multi-nube. Nada en las definiciones obliga a una empresa a elegir un solo camino.

Vale la pena nombrar una trampa directamente: correr cargas de trabajo en 2 regiones distintas del mismo proveedor, 2 regiones de AWS, por ejemplo, no es multi-nube. La multi-nube significa específicamente proveedores separados. Correr en varias regiones de un mismo proveedor es una técnica de resiliencia dentro de una sola nube, un concepto distinto que este curso cubre más adelante.

Un segundo malentendido: la multi-nube no significa automáticamente que una aplicación sobreviva a la interrupción de un proveedor. Repartir cargas de trabajo sin relación entre 2 proveedores, la app de un equipo en AWS, la app de otro equipo en Azure, reduce el riesgo de contrato y precio, pero si una sola aplicación solo corre en uno de esos proveedores, esa aplicación igual se cae cuando ese proveedor falla. La resiliencia real entre proveedores significa diseñar activamente una carga de trabajo para correr en más de una nube a la vez, algo más difícil y más raro de lo que sugieren las cifras de adopción de multi-nube.

Lo que te llevas de aquí

Haz 2 preguntas, no una, antes de etiquetar un montaje. ¿Incluye una pieza privada o local conectada a una nube pública? Si la respuesta es sí, esa es la mitad híbrida. ¿Involucra a más de un proveedor público separado? Si la respuesta es sí, esa es la mitad multi-nube. Un montaje puede responder sí a ambas, a una, o a ninguna, y la etiqueta solo importa porque revela qué problema estaba resolviendo realmente la organización: conservar algo que no puede mover, o negarse a depender de quien no tiene por qué depender. El próximo tema deja atrás los modelos de despliegue y pasa a la pregunta en la que termina cada una de estas decisiones: cuánto cuesta en realidad.