Detrás hay edificios llenos de servidores físicos, con redundancia eléctrica, refrigeración y conectividad duplicada. Pero la pieza que hace posible el modelo es la virtualización: una capa de software que divide cada servidor físico en varios hosts virtuales independientes. Gracias a ella, un mismo equipo puede alojar cargas de trabajo de clientes distintos, aislados entre sí, y el suministrador puede crear una máquina nueva en segundos sin tocar componentes. Esa es también la razón de que puedas duplicar tu capacidad un lunes de rebajas y devolverla el martes: no estás comprando máquinas, estás reservando porciones de una capacidad que ya existe.

Los proveedores organizan sus centros de datos en regiones geográficas y zonas de disponibilidad dentro de cada región, de modo que una incidencia física en un edificio no tumbe el servicio. Elegir región no es un detalle menor: determina la latencia que notarán tus usuarios y dónde residen legalmente tus datos.

Esta es la parte que más confusión genera, y de ella depende el reparto de responsabilidades cuando algo va mal. El suministrador se ocupa siempre de la seguridad de la nube: el edificio, el hardware, la red física, la capa de virtualización. El cliente se ocupa siempre de la seguridad en la nube: quién accede, con qué permisos, cómo se configuran los servicios y qué datos se suben. La frontera exacta se mueve según el modelo de servicio que contrates, y lo verás con detalle en la sección de IaaS, PaaS y SaaS. Una configuración incorrecta por parte del cliente sigue siendo responsabilidad del cliente. Es el origen de la mayoría de los incidentes que se atribuyen a "fallos de la nube". Si esta parte te preocupa, es exactamente el terreno de la seguridad y el cumplimiento normativo↗.

La infraestructura pertenece a un suministrador que la ofrece a cualquier cliente. Los recursos físicos se comparten entre muchas organizaciones, aunque cada una esté lógicamente aislada de las demás. Es el modelo con menor coste de entrada, porque no hay inversión inicial, y el que mejor escala. Encaja bien en aplicaciones web, entornos de desarrollo y pruebas, almacenamiento, copias de seguridad y cualquier carga con demanda irregular.

La infraestructura se dedica a una sola organización. Puede estar en su propio centro de datos o alojada en un tercero, pero no se comparte. Ofrece más control sobre la configuración, la ubicación de los datos y el aislamiento, a cambio de un coste fijo más alto y de una escalabilidad limitada por la capacidad contratada. Suelen necesitarla organizaciones con requisitos regulatorios estrictos, sectores supervisados o entornos donde el dato no puede salir de un perímetro determinado.

Combina pública y privada, con conectividad entre ambas, y reparte las cargas de trabajo según convenga. Lo habitual es mantener en privado los sistemas con datos sensibles o con requisitos de cumplimiento, y llevar a pública lo que necesita elasticidad. Es el modelo más frecuente en empresas medianas y grandes, sencillamente porque nadie migra todo de golpe: la híbrida suele ser el resultado natural de una migración progresiva, no una decisión de partida.

Consiste en usar varios proveedores de nube pública a la vez. No es lo mismo que híbrida: la híbrida mezcla pública y privada; la multicloud mezcla proveedores. Se adopta para evitar la dependencia de uno solo, para aprovechar servicios concretos que cada proveedor hace especialmente bien, o por herencia de fusiones y adquisiciones. El precio a pagar es la complejidad: dos consolas, dos modelos de facturación, dos formas de gestionar identidades y un equipo que tiene que conocer ambas.

El suministrador entrega los ladrillos: máquinas virtuales, almacenamiento, redes y capacidad de cálculo. Tú instalas encima el sistema operativo, el middleware y tus aplicaciones, y te ocupas de mantenerlos actualizados. Es el modelo con más libertad y más trabajo. Es también el destino natural de una migración lift and shift, cuando se mueven servidores existentes a la nube sin rediseñarlos.

El suministrador entrega además el sistema operativo, el motor de ejecución, las bases de datos gestionadas y las herramientas de despliegue. Tú solo aportas el código y los datos. Acelera mucho el desarrollo porque el equipo deja de administrar servidores, pero te ata más a la forma de trabajar de ese suministrador concreto. Es el modelo habitual para aplicaciones nuevas y para la modernización de aplicaciones legacy↗.

El suministrador entrega la aplicación terminada, accesible por navegador y contratada por suscripción. Se encarga de todo: infraestructura, actualizaciones, copias y disponibilidad. Tú gestionas usuarios, permisos y tus propios datos. Es el modelo que más se usa sin saber que se usa: el correo corporativo, el CRM, la videoconferencia y la ofimática en línea son SaaS.

Casi ninguna empresa decide un día repartir sus sistemas entre varias nubes: llega ahí sin habérselo propuesto. El correo y la ofimática se contratan a un proveedor de nube. El equipo de desarrollo levanta un entorno de pruebas en otro, porque le ofrece la base de datos gestionada que necesita. Marketing contrata una herramienta de analítica que funciona sobre Google Cloud. Un año después, la tecnología de la organización está repartida entre tres plataformas distintas y nadie ha tomado esa decisión de forma explícita. Eso es multinube, aunque nadie la haya llamado así. No es necesariamente un problema. La multinube ofrece flexibilidad real: permite elegir en cada caso el entorno que mejor encaja con las necesidades de cada carga de trabajo, reduce la dependencia de un suministrador único y facilita integrar empresas adquiridas que llegan con su propia tecnología. Muchas organizaciones la adoptan a propósito precisamente por eso.

El coste está en la gestión.

Cada nube ofrece su propia consola, su modelo de facturación y su forma de gestionar identidades, y Google Cloud, Microsoft Azure y Amazon Web Services llaman de forma distinta a servicios de computación equivalentes. El software que funciona sin ajustes en una plataforma rara vez se mueve limpio a otra, y los equipos informáticos tienen que dominar dos o tres entornos en lugar de uno. La capacidad de computación se contrata por separado, se mide por separado y se paga por separado, así que la factura total deja de ser legible de un vistazo.

La pregunta útil no es si conviene trabajar con una nube o con varias, sino si la organización tiene quién gobierne lo que ya tiene. Una multinube ordenada —con inventario de los sistemas informáticos y del software contratado, responsables asignados y control de gasto— aporta flexibilidad y capacidad de negociación. Una multinube accidental solo multiplica facturas, entornos sin dueño y puntos ciegos. La diferencia entre una cosa y otra no es la tecnología: son las necesidades que las empresas se hayan molestado en definir antes de contratar