Introducción a la Computación en la Nube
Esta unidad introduce qué es la computación en la nube, por qué surgió, cómo se clasifica, qué oportunidades y desafíos plantea y qué vocabulario mínimo necesitás para moverte con soltura en el resto del cuatrimestre.
1. La idea de fondo
Durante décadas, montar una aplicación significaba comprar servidores, refrigerarlos, alimentarlos, asegurarlos y rezar para que no se rompieran un domingo a las 3 de la mañana. La computación en la nube cambia esa ecuación: en lugar de poseer la infraestructura, la alquilás bajo demanda a un proveedor especializado, accedés a ella por internet y pagás solo por lo que usás.
La computación en la nube es ante todo un modelo de negocio.
La idea de fondo
El cambio no es tanto técnico como económico: en lugar de comprar y mantener hardware propio, pagás por lo que usás. Se pasa de una gran inversión inicial (CAPEX) a un gasto operativo flexible (OPEX).
Modelos de servicio
IaaSAlquilás la infraestructura cruda: servidores, red, almacenamiento.
PaaSAlquilás una plataforma lista para desplegar tu código.
SaaSUsás el software ya terminado, sin gestionar nada por debajo.
Para tener en cuenta
- Cada modelo traslada más responsabilidad (y costo operativo) al proveedor.
- La nube no siempre es más barata: conviene cuando la demanda es variable.
2. Definición formal
La definición de referencia es la del NIST (National Institute of Standards and Technology, EE. UU.), publicada en 2011. Sigue vigente porque describe el modelo en términos abstractos, no atados a un proveedor.
Definición NIST de computación en la nube.
Texto original
"Un modelo que permite el acceso ubicuo, conveniente y bajo demanda a través de la red a un conjunto compartido de recursos informáticos configurables (redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser rápidamente provistos y liberados con un esfuerzo mínimo de gestión."
Tres componentes del modelo
5 característicasAtributos esenciales que definen qué es y qué no es la nube.
3 modelos de servicioIaaS, PaaS, SaaS (y derivados modernos como FaaS).
4 modelos de desplieguePública, privada, híbrida y comunitaria.
Para tener en cuenta
- Si a una solución le falta alguna de las 5 características, técnicamente no es nube.
- "Tener un servidor en un data center" no equivale a "estar en la nube".
3. Las cinco características esenciales
Según NIST, una solución debe cumplir cinco propiedades para considerarse computación en la nube. La primera es el autoservicio bajo demanda: el usuario aprovisiona recursos cuando los necesita mediante un portal o una API, sin intervención humana del proveedor. La segunda es el acceso amplio a la red: los servicios están disponibles vía mecanismos estándar (HTTP/HTTPS, APIs REST) desde cualquier dispositivo. La tercera es la agrupación de recursos o multi-tenancy: el proveedor comparte hardware entre clientes mediante virtualización, y el cliente no ve ni controla la ubicación exacta.
La cuarta es la elasticidad rápida: la capacidad escala hacia arriba o abajo de forma ágil, idealmente automática, de modo que desde la perspectiva del cliente los recursos parecen infinitos. La quinta es el servicio medido: el uso se monitorea y se factura por consumo (CPU-hora, GB almacenados, requests, ancho de banda) con reportes detallados. Si a una solución le falta alguna de estas cinco, técnicamente no es nube, aunque viva en un data center remoto.
4. Modelos de servicio
NIST distingue tres modelos clásicos según cuánto administra el cliente y cuánto el proveedor —IaaS, PaaS y SaaS— a los que la industria sumó después dos variantes modernas que conviene presentar en el mismo movimiento: FaaS (serverless) y BaaS. La pirámide va de menos abstracción y más control (IaaS) a más abstracción y menos control (SaaS, BaaS), con FaaS como una rama de PaaS llevada al extremo del event-driven.
El proveedor entrega máquinas virtuales, discos y redes. El cliente administra el sistema operativo, el middleware, el runtime y la aplicación.
Metáfora
Como alquilar un terreno con servicios básicos: vos construís y mantenés la casa.
Según la nube
Cuándo conviene usarlo
- Migración "lift and shift" de aplicaciones existentes.
- Cargas con requisitos específicos de SO o kernel.
- Necesidad de control total sobre el entorno de ejecución.
Más detalle del modelo, productos por proveedor y cuándo conviene en el recurso VPS.
.)
El proveedor entrega un entorno de ejecución gestionado (runtime, base de datos, middleware). El cliente solo despliega su código y sus datos.
Metáfora
Como alquilar un local comercial con instalación eléctrica, agua y aire acondicionado: solo tenés que traer tu mercadería y atender.
Según la nube
Cuándo conviene usarlo
- Equipos chicos que necesitan velocidad de desarrollo.
- Aplicaciones web/API estándar sin requisitos de bajo nivel.
- Prototipos y MVPs donde el time-to-market es lo más importante.
El proveedor entrega una aplicación lista para usar vía navegador o API. El cliente solo carga sus datos y configura el comportamiento.
Metáfora
Como reservar una mesa en un restaurante: no cocinás, no comprás los insumos, solo elegís del menú.
Ejemplos cotidianos
Cuándo conviene usarlo
- Funciones genéricas que ya están bien resueltas por el mercado (email, CRM, ofimática).
- Equipos distribuidos que necesitan colaboración inmediata.
- Casos donde no aporta valor "reinventar la rueda".
El proveedor ejecuta código en respuesta a eventos. No hay servidor que aprovisionar: subís una función, definís el disparador y se ejecuta cuando corresponde. Se factura por invocación y por tiempo de ejecución.
Metáfora
Como un taxi: aparece solo cuando lo llamás, te lleva y se va. No pagás cuando no lo usás.
Según la nube
Cuándo conviene usarlo
- Tareas event-driven: procesar un upload, responder un webhook.
- Cargas esporádicas o impredecibles.
- Glue code: pequeñas integraciones entre servicios.
Más detalle del modelo y productos por proveedor en el recurso serverless.
Más allá de los tres modelos clásicos NIST y de FaaS, hay una variante moderna que conviene tener identificada y una capa transversal que aparece en casi cualquier producto. Las plataformas BaaS (Backend as a Service, como Firebase o Supabase) llevan al extremo la lógica de SaaS aplicada al backend: integran auth, base de datos, storage y funciones en un solo SDK que el frontend consume directo. Y las redes CDN (CloudFront, Cloudflare, Fastly) no son un modelo de servicio en sí mismo: son una capa de distribución global que se monta sobre cualquiera de los modelos anteriores para servir contenido cerca del usuario.
IaaS vs SaaS: responsabilidades
IaaS
- Control total sobre SO, red y stack.
- Flexibilidad para casos atípicos.
- Cliente responsable de parches, backups, monitoreo.
- Más costo operativo y necesidad de expertise.
SaaS
- Listo para usar, sin operación.
- Actualizaciones automáticas a cargo del proveedor.
- Poca personalización y dependencia total del proveedor.
- Datos sensibles fuera del control directo del cliente.
5. Modelos de despliegue
Además del "qué" entrega la nube, importa "dónde" y "para quién" se despliega. NIST define cuatro modelos clásicos, a los que la industria suele sumar uno quinto como variante moderna. La nube pública es la más común y económica al inicio: infraestructura propiedad de un proveedor (AWS, Azure, GCP) y compartida entre múltiples clientes. La nube privada, en el otro extremo, es infraestructura dedicada a una sola organización —on-premise o tercerizada— con mayor control y compliance, pero también mayor costo.
Entre esos dos extremos aparecen las variantes mixtas: la nube híbrida combina pública y privada, moviendo datos y aplicaciones entre ambas según la sensibilidad o la carga; la nube comunitaria se comparte entre organizaciones con intereses comunes (un consorcio universitario, organismos de un mismo sector); y el multi-cloud, cada vez más adoptado, usa simultáneamente varios proveedores públicos para evitar dependencia (vendor lock-in) y aprovechar lo mejor de cada uno.
6. Una breve historia
La computación en la nube no apareció de la nada: es la evolución de varias décadas de tendencias técnicas y económicas.
- Años 60-70 · Mainframes. Cómputo centralizado con terminales tontas. Tiempo compartido entre usuarios: la idea de "alquilar cómputo" ya existía.
- Años 80-90 · Cliente-servidor. Las PCs ganan poder local y se conectan a servidores. Se descentraliza.
- Años 90-2000 · Internet y la web. Las aplicaciones se vuelven accesibles globalmente desde el navegador.
- Años 2000 · Virtualización. Múltiples sistemas operativos sobre un mismo hardware (VMware, Xen). Es la base técnica de la nube moderna.
- 2006 · Nace AWS. Amazon lanza S3 y EC2, abriendo el mercado de la nube pública tal como la conocemos hoy.
- 2010 en adelante · Madurez. Aparecen Azure, GCP y un ecosistema completo de servicios gestionados: bases de datos, IA, big data, IoT, serverless.
7. Beneficios y desafíos
Adoptar la nube no es solo una decisión técnica: implica beneficios concretos pero también nuevos riesgos y compromisos.
Beneficios vs Desafíos de la nube
Beneficios
- Conversión de CAPEX en OPEX: sin grandes inversiones iniciales.
- Escalabilidad casi instantánea ante picos de demanda.
- Alcance global: desplegar en otra región en minutos.
- Alta disponibilidad y recuperación ante desastres más simples.
- Acceso a servicios avanzados (IA, big data, IoT) listos para usar.
- Foco en el negocio, no en operación de infraestructura.
Desafíos
- Vendor lock-in: dependencia técnica y económica del proveedor.
- Seguridad y privacidad de los datos en infraestructura compartida.
- Cumplimiento normativo (GDPR, Ley 25.326, soberanía de datos).
- Latencia y dependencia de la conectividad.
- Costos descontrolados sin gobernanza ("bill shock").
- Nuevas habilidades requeridas en los equipos técnicos.
Qué suele pasar
Una empresa migra sus servidores tal cual a IaaS y termina pagando más que antes, sin haber ganado en agilidad ni en disponibilidad.
Por qué
Se replica el modelo on-premise sin aprovechar elasticidad, servicios gestionados ni reservas de capacidad. La nube cobra cada hora, todos los meses, sin importar que el servidor esté ocioso.
Cómo evitarlo
Antes de migrar, identificá qué cargas se benefician realmente de la nube (variables, estacionales, globales) y cuáles conviene dejar on-premise.
Qué suele pasar
Se usa la cuenta raíz para todo, sin crear roles ni usuarios, y se exponen claves de acceso en repositorios públicos.
Por qué
Es el camino más rápido al empezar. El problema aparece cuando alguien descubre las claves y empieza a minar criptomonedas a costa de tu cuenta.
Cómo evitarlo
Activá MFA en la cuenta raíz, usá IAM con permisos mínimos y nunca subas credenciales al control de versiones.
.)
Casi todos los proveedores tienen capa gratuita (free tier): aprovechala para experimentar durante el cuatrimestre sin gastar un peso.
Etiquetá (taggeá) cada recurso con su proyecto, ambiente y responsable. Es la única forma escalable de saber después qué pagás y por qué.
CAPEX vs OPEX
CAPEX (modelo tradicional)
- Activo propio, amortizable.
- Costo predecible una vez comprado.
- Gran inversión inicial.
- Difícil ajustar capacidad rápido.
OPEX (modelo nube)
- Sin desembolso inicial.
- Capacidad ajustable mes a mes.
- Gasto recurrente que nunca termina.
- Puede salirse de control sin monitoreo.
8. Infraestructura física: regiones y zonas
Aunque desde el cliente la nube parezca "etérea", por detrás hay centros de datos físicos distribuidos por el planeta. Dos conceptos clave organizan esa geografía:
Ubicación geográfica donde el proveedor tiene un conjunto de centros de datos. Cada región tiene un identificador (por ejemplo, us-east-1, sa-east-1, eu-west-3).
Por qué importa
La región condiciona latencia hacia los usuarios, precio de los servicios y compliance de datos (algunas regulaciones exigen mantener los datos dentro del país).
Cuándo conviene elegirla con cuidado
- Cuando los usuarios están concentrados geográficamente.
- Cuando aplican leyes de soberanía de datos.
- Cuando el costo entre regiones cambia significativamente.
.)
Cada región se divide en varias zonas de disponibilidad: centros de datos físicamente aislados entre sí dentro de la misma región, con energía, red y refrigeración independientes.
Metáfora
Como tener dos depósitos en barrios distintos de la misma ciudad: si se inunda uno, el otro sigue operando.
Cuándo aprovecharlas
- Para alta disponibilidad: replicar la aplicación en al menos dos AZ.
- Para tolerancia a fallos de un data center sin perder latencia.
- Para configuraciones activo-activo y bases de datos replicadas.
9. Principales proveedores
El mercado está dominado por tres grandes (los "hyperscalers"), pero el ecosistema es más amplio y diverso de lo que parece a simple vista. Conviene distinguir tres capas:
Hyperscalers globales
- Amazon Web Services (AWS): pionero y líder del mercado, con la oferta de servicios más amplia.
- Microsoft Azure: fuerte integración con el ecosistema corporativo Microsoft y con escenarios híbridos.
- Google Cloud Platform (GCP): destacado en datos, analítica e inteligencia artificial.
Otros proveedores cloud relevantes
- IBM Cloud, Oracle Cloud, Alibaba Cloud: presencia regional fuerte y nichos corporativos específicos.
VPS providers y "cloud simple"
- DigitalOcean, Linode (Akamai), Vultr, Hetzner: foco en VPS y servicios gestionados simples; precios más predecibles y curva de aprendizaje plana frente a los hyperscalers.
10. Casos de uso típicos
- Aplicaciones y sitios web escalables.
- Procesamiento de datos masivos y analítica (big data, data lakes).
- Machine learning e inteligencia artificial generativa.
- Backups, archivado y planes de recuperación ante desastres.
- Entornos de desarrollo y prueba bajo demanda.
- Streaming de contenidos y videojuegos online.
- Internet de las Cosas (IoT) y procesamiento en el borde (edge computing).
- Cargas batch puntuales: render de video, simulaciones científicas, procesamientos financieros.
11. ¿Cómo decidir si un proyecto va a la nube?
- Caracterizá la carga: ¿es constante, variable, estacional, en picos?
- Evaluá los datos: ¿hay restricciones legales sobre dónde pueden alojarse?
- Estimá el costo: compará TCO (Total Cost of Ownership) on-premise vs nube a 3-5 años.
- Mirá el equipo: ¿tenés gente que sepa operar en la nube o necesitás capacitación?
- Definí la estrategia: lift-and-shift, refactor a PaaS, rebuild cloud-native o quedarse on-premise.
12. Glosario rápido
13. Para profundizar
NIST · lectura ~15 min
La definición canónica de "computación en la nube". Corto, claro y la base teórica de toda la unidad. Imprescindible.
Ir al recursoAWS · lectura por pilares
Conjunto de buenas prácticas organizadas en 6 pilares (operación, seguridad, confiabilidad, eficiencia, costo, sustentabilidad). Útil aún si no usás AWS: los principios son universales.
Ir al recursoLectura larga · referencia académica
Libro de cabecera para cursos universitarios. Cubre fundamentos, arquitectura y patrones de diseño en la nube con un enfoque proveedor-agnóstico.
14. Cierre
La nube no es solo "alquilar servidores": es un cambio de modelo operativo y económico.
Qué hay que llevarse
Adoptar la nube redefine cómo se diseñan, despliegan y escalan los sistemas. El cambio técnico (virtualización, APIs, automatización) habilita un cambio económico (CAPEX → OPEX) y un cambio organizacional (foco en el negocio, no en la operación de fierros).
Qué viene
Unidad 2Virtualización y containerización: las dos capas técnicas que sostienen la nube por debajo.
Unidad 3Tres leyes que moldean cualquier arquitectura distribuida: Conway, Gall y CAP.
Unidad 4Metodologías ágiles y ciclo de vida del software: el proceso humano detrás de la nube.
Unidad 5Conceptos básicos de IA generativa y cómo se integra al stack cloud.
Unidad 6Aplicaciones concretas: cómo se combinan los servicios para armar un producto real.
Antes de seguir
- Asegurate de poder explicar las 5 características esenciales con tus palabras.
- Distinguí IaaS, PaaS, SaaS y FaaS con un ejemplo concreto de cada uno.
- Creá una cuenta gratuita en alguno de los tres grandes proveedores para experimentar en la unidad siguiente.