La nube: del diagrama de red de los años 90 a la definición NIST de 2011, y los tres modelos de servicio
Qué es la nube, su origen real (los diagramas de red de los 90, AWS lanzando S3 y EC2 en 2006, la definición NIST 800-145 de 2011), los tres modelos de servicio (IaaS, PaaS, SaaS), los cuatro modelos de despliegue, y por qué entender la diferencia importa para decisiones de infraestructura y herramientas.
El equipo detrás de Polimake. Exploramos la intersección entre tecnología, creatividad y automatización.
La nube —cloud computing— es la entrega de recursos de computación (servidores, almacenamiento, redes, bases de datos, software) como servicios bajo demanda a través de internet, en lugar de poseer y mantener esa infraestructura localmente. La definición suena abstracta y por eso pasa por encima de buena parte de la literatura: lo importante no es la metáfora del término, sino los modelos concretos de servicio que la nube ofrece y las decisiones que cada uno implica.
Vale la pena empezar por el origen real, porque el uso casual del término ha diluido su significado hasta el punto de que casi cualquier servicio digital se llama "nube" sin que la palabra signifique mucho.
El origen del término y la era moderna desde 2006
El símbolo de nube en diagramas de red se remonta a los años 90, cuando ingenieros usaban una nube dibujada para representar redes externas cuyo interior no necesitaban detallar. "Tu sistema se conecta con eso, lo que hay dentro de la nube no nos importa para este diagrama". La metáfora visual era pragmática: una abstracción para no tener que dibujar la infraestructura externa cada vez.
El uso del término "cloud computing" en su sentido moderno se atribuye habitualmente a Eric Schmidt, entonces CEO de Google, en una intervención en la Search Engine Strategies Conference en agosto de 2006, donde dijo "we call it cloud computing — they should be in a cloud somewhere". Aunque hubo usos previos en círculos académicos y técnicos, esa intervención popularizó la expresión.
Más importante que el término fue lo que ocurrió ese mismo año desde el lado técnico:
Marzo de 2006: Amazon lanza S3 (Simple Storage Service), permitiendo almacenamiento de objetos a través de API web. Cualquier desarrollador podía empezar a almacenar archivos remotamente con coste por uso.
Agosto de 2006: Amazon lanza EC2 (Elastic Compute Cloud), permitiendo alquilar capacidad de cómputo virtualizada. Por primera vez una empresa o desarrollador podía levantar servidores sin comprar hardware ni mantener data center propio.
Esos dos lanzamientos marcaron el nacimiento de la infraestructura cloud moderna. Google Cloud Platform entró al mercado en 2008. Microsoft Azure se lanzó comercialmente en febrero de 2010. La nube como sector competitivo arrancó ahí.
La definición canónica: NIST 800-145 (2011)
La definición más rigurosa y citada de cloud computing es la del National Institute of Standards and Technology de Estados Unidos, publicada en la Special Publication 800-145 en septiembre de 2011 y firmada por Peter Mell y Timothy Grance. Es un documento corto (~7 páginas) que sigue siendo referencia académica e industrial.
NIST define cloud computing por cinco características esenciales, tres modelos de servicio y cuatro modelos de despliegue.
Las cinco características esenciales
On-demand self-service. El usuario provisiona recursos sin intervención humana del proveedor. Levantas un servidor con un clic, no rellenas un formulario y esperas días.
Broad network access. Los recursos están disponibles por la red y accesibles desde cualquier dispositivo estándar (móvil, ordenador, tablet) — no requieren cliente especializado.
Resource pooling. Los recursos del proveedor están agrupados y se asignan dinámicamente entre múltiples clientes (multi-tenancy). El usuario no sabe ni necesita saber dónde físicamente está su servidor.
Rapid elasticity. Los recursos pueden escalarse hacia arriba o abajo rápidamente, en muchos casos automáticamente, según demanda. Lo que antes requería comprar hardware nuevo ahora se hace ajustando una variable.
Measured service. El uso se monitoriza y factura por consumo. Pagas por lo que usas, no por capacidad instalada que puedas no usar.
Si un servicio no cumple esas cinco características, técnicamente no es cloud computing en el sentido NIST. Es alojamiento web tradicional con apariencia moderna.
Los tres modelos de servicio
Esta es la distinción operativa más importante para tomar decisiones de infraestructura. NIST identifica tres niveles de servicio cloud según qué provee el proveedor y qué gestiona el cliente:
IaaS — Infrastructure as a Service
El proveedor entrega infraestructura virtualizada: capacidad de cómputo, almacenamiento, red. El cliente gestiona sistema operativo, runtimes, datos, aplicaciones. Ejemplos: AWS EC2 + S3, Google Compute Engine, Azure Virtual Machines, DigitalOcean Droplets, Linode.
Es el nivel más flexible y el que requiere más conocimiento técnico. Adecuado para empresas que necesitan control fino sobre su infraestructura o que ejecutan cargas no estandarizadas.
PaaS — Platform as a Service
El proveedor entrega una plataforma de desarrollo y ejecución con runtime, sistema operativo, escalado automático ya configurados. El cliente solo se encarga del código de aplicación y los datos. Ejemplos: Heroku, Vercel, Netlify, AWS Elastic Beanstalk, Google App Engine, Azure App Service.
Reduce dramáticamente la complejidad de despliegue. Adecuado para equipos de desarrollo que quieren centrarse en el código y no en la infraestructura.
SaaS — Software as a Service
El proveedor entrega una aplicación completa lista para usar. El cliente solo configura, usa y opera dentro de los límites que la aplicación permite. Ejemplos: Gmail, Salesforce, Slack, Notion, Figma, Polimake.
Es el modelo más accesible y el que ha dominado el consumo cloud. La inmensa mayoría de empresas medianas y pequeñas consumen cloud a través de docenas de SaaS sin ser conscientes de que están en cloud.
La distinción importa porque las decisiones de inversión, control, riesgo y migración son completamente distintas en cada nivel. Una empresa con dependencia de varios SaaS críticos tiene riesgos distintos de una con infraestructura propia en IaaS.
Los cuatro modelos de despliegue
NIST también identifica cuatro modelos según quién opera la infraestructura y para quién:
Cloud público. Infraestructura propiedad del proveedor, ofrecida abiertamente al mercado. AWS, Azure, GCP en su forma estándar son cloud público. La mayoría de las empresas pequeñas y medianas usan cloud público.
Cloud privado. Infraestructura dedicada exclusivamente a una organización (puede operarla la propia organización o un tercero, pero el uso es exclusivo). Suele justificarse por requisitos regulatorios, de seguridad o de personalización extrema.
Cloud híbrido. Combinación de público y privado, con datos y aplicaciones moviéndose entre ambos según necesidad. Modelo común en empresas grandes con cargas mixtas.
Cloud comunitario. Infraestructura compartida por varias organizaciones con preocupaciones comunes (ej. consorcios de healthcare con requisitos regulatorios similares). Menos común en práctica que los otros tres.
Por qué importa entender estas distinciones
La conversación habitual sobre nube en empresas no técnicas suele tratar todo como una caja negra etiquetada "cloud". Esa simplificación esconde decisiones que importan:
Coste estructural diferente por modelo. SaaS tiene coste predecible pero sin economías de escala (pagas por usuario o por consumo); IaaS tiene coste variable que puede explotar con uso o caer con optimización. Una empresa que consume cloud sin entender la diferencia entre modelos suele tener facturas más altas de lo necesario.
Riesgo de vendor lock-in distinto. Migrar de un SaaS a otro suele ser doloroso pero acotado. Migrar entre proveedores IaaS implica re-arquitectura completa de la solución. Las decisiones tecnológicas iniciales fijan caminos durante años.
Seguridad y compliance. Cada modelo de servicio tiene un responsibility model distinto: en IaaS gestionas sistema operativo y aplicación; en PaaS solo aplicación; en SaaS solo configuración. Confusión sobre quién es responsable de qué genera vulnerabilidades reales.
Performance y latencia. El modelo de despliegue (público vs. privado vs. híbrido) afecta latencia, throughput y experiencia de usuario en formas que la categoría genérica "está en la nube" no captura.
La realidad 2026: nube ubicua, pero con matices
Diecisiete años después del lanzamiento de AWS S3, la nube ha pasado de tendencia a infraestructura estándar. El mercado global de cloud computing supera los 500.000 millones de dólares anuales y crece dos dígitos sostenidamente. La práctica totalidad de empresas medianas y grandes consumen cloud en algún nivel.
Algunas tendencias del estado actual:
Multi-cloud y híbrido como estándar. Pocas empresas grandes confían su operación a un único proveedor. La diversificación es protección contra outages, contra subidas de precio, y contra cambios estratégicos del proveedor.
Sovereign cloud. Crecimiento de proveedores cloud localizados por jurisdicción (especialmente en Europa) por preocupaciones de soberanía de datos y cumplimiento del RGPD. Iniciativas como GAIA-X (europea) reflejan esa preocupación.
Edge computing. El reverso de la nube centralizada — llevar capacidad de cómputo cerca del usuario final para reducir latencia. Cloudflare Workers, AWS Wavelength, Azure Edge Zones son ejemplos.
FinOps como disciplina. La gestión financiera del consumo cloud se ha convertido en función dedicada en muchas empresas, con la fundación FinOps Foundation (creada 2019) consolidando prácticas.
Repatriation parcial. Algunas empresas grandes han movido cargas de cloud público a infraestructura propia o cloud privado al hacer cuentas y descubrir que ciertas cargas son más baratas on-premise. 37signals (Basecamp, HEY) hizo público en 2022-2023 su movimiento de salida de AWS, y han publicado análisis detallados de los ahorros.
Errores comunes en uso de cloud
Confundir SaaS con la nube entera. "Estamos en la nube" cuando lo que se quiere decir es "usamos varias herramientas SaaS" no es lo mismo que tener una estrategia cloud.
Subestimar el coste a largo plazo. Cloud público parece barato al inicio. A escala, especialmente con cargas predecibles, puede ser más caro que infraestructura propia. Las cuentas honestas requieren modelo de coste a 3-5 años.
Vendor lock-in invisible. Construir aplicaciones que dependen de servicios proprietary de un proveedor (Lambda en AWS, Cosmos DB en Azure) reduce flexibilidad de migración significativamente.
No diseñar para fallos de proveedor. Outages de AWS, Azure, GCP han ocurrido y ocurrirán. Asumir 100% de uptime es planificación irresponsable.
Olvidar el RGPD y soberanía de datos. Especialmente para empresas europeas, dónde físicamente residen los datos importa legalmente. No todos los proveedores ofrecen residencia europea garantizada para todos los servicios.
Saturación de SaaS. El número de herramientas SaaS por empresa ha crecido exponencialmente. Sin gobernanza, las empresas acumulan suscripciones duplicadas, abandonadas o redundantes con coste acumulado significativo.
La nube y operaciones creativas
Para un equipo de marketing, agencia o producción audiovisual, la nube no es decisión técnica abstracta — es la infraestructura sobre la que vive todo el trabajo creativo en 2026. El asset management, la colaboración entre disciplinas, las herramientas de producción, el archivo de proyectos completados, todo está en la nube. La elección de qué servicios usar y cómo organizarlos define en buena medida la velocidad, coste y seguridad de la operación creativa.
Esa elección encaja en operaciones creativas: la producción de contenidos requiere infraestructura cloud que permita colaboración y reutilización, la gestión de marca necesita repositorios accesibles que mantengan versiones controladas, los flujos de aprobación operan sobre plataformas que conectan stakeholders distribuidos.
En Polimake esa lógica vive en una plataforma de operaciones creativas SaaS que coordina Studio (planificación), Studio (producción) y Media (asset management) — para que los activos creativos vivan en un sistema diseñado para creativo, no dispersos entre Drive, Dropbox, WeTransfer y carpetas locales.
Si lideras tecnología, operaciones o marketing en una empresa que toma decisiones de cloud y has llegado aquí buscando una respuesta, lo más útil que puedes llevarte de este artículo es probablemente la distinción que casi nadie respeta: "estar en la nube" no es una decisión; es muchas decisiones distintas según modelo de servicio (IaaS/PaaS/SaaS) y modelo de despliegue (público/privado/híbrido). Tomar decisiones cloud sin la granularidad correcta produce facturas más altas, lock-in inadvertido, y vulnerabilidades que se descubren tarde.
Para complementar, trabajar en la nube cubre los beneficios prácticos en equipos remotos, SaaS profundiza en el modelo de servicio más usado, y activos digitales cubre la gestión de los activos que viven en la nube en proyectos creativos.
Referencias rápidas
- SaaS (Software as a Service) — el modelo más extendido en consumo empresarial.
- Trabajar en la nube — los beneficios operativos en equipos.
- Activos digitales — qué se almacena en la nube en operaciones creativas.
- CMS — categoría de SaaS especializada en gestión de contenido.
- Hosting — categoría tradicional adyacente a la nube.