El cloud computing (computación en la nube) es la entrega bajo demanda de recursos informáticos (servidores, almacenamiento, bases de datos, red, software) a través de Internet, con un modelo de pago por uso. En lugar de comprar, instalar y mantener hardware propio en un centro de datos físico, una empresa alquila esos recursos a un proveedor (AWS, Microsoft Azure, Google Cloud, etc.) y los consume como un servicio. Esto es relevante porque cambia radicalmente el modelo de costes (de inversión CAPEX a gasto operativo OPEX), permite escalar en minutos en lugar de meses y traslada parte de la responsabilidad operativa al proveedor. Comprender los modelos de servicio, los modelos de despliegue y, sobre todo, el reparto de responsabilidades es la base de cualquier decisión arquitectónica en la nube.

1. Qué problema resuelve la nube y características esenciales.
2. Modelos de servicio: IaaS, PaaS y SaaS.
3. Modelos de despliegue: público, privado, híbrido y multinube.
4. El modelo de responsabilidad compartida.
5. Geografía de la nube: regiones, zonas de disponibilidad y edge.
6. Errores comunes y consejos.
7. Ejercicios y soluciones.

Antes de la nube, desplegar una aplicación implicaba comprar servidores, esperar semanas a su entrega, instalarlos en un rack, configurar red y refrigeración, y mantenerlos durante años aunque la demanda fuera variable. La nube resuelve esto con cinco características esenciales (definidas por el NIST, el instituto de estándares estadounidense):

• Autoservicio bajo demanda: el usuario aprovisiona recursos por sí mismo, sin intervención humana del proveedor.
• Acceso amplio por red: los recursos están disponibles a través de la red mediante mecanismos estándar.
• Agrupación de recursos (resource pooling): el proveedor sirve a múltiples clientes con infraestructura compartida (multi-tenant).
• Elasticidad rápida: la capacidad escala hacia arriba o hacia abajo de forma automática según la demanda.
• Servicio medido (measured service): el consumo se mide y se factura de forma transparente (pago por uso).

Los tres modelos clásicos se diferencian por cuánto gestiona el proveedor y cuánto gestionas tú. Una analogía útil es la pizza: hacerla en casa (on-premises), comprar la masa congelada (IaaS), pedirla a domicilio (PaaS) o ir a un restaurante (SaaS).

• IaaS (Infraestructura como Servicio): alquilas los bloques básicos (CPU, RAM, disco, red) normalmente como máquinas virtuales. Tú instalas el sistema operativo, el runtime y la aplicación. Máxima flexibilidad, máxima responsabilidad.
• PaaS (Plataforma como Servicio): subes tu código y el proveedor se encarga del sistema operativo, los parches, el escalado y el balanceo. Ideal para acelerar el desarrollo sin gestionar servidores.
• SaaS (Software como Servicio): consumes una aplicación completa por suscripción. No gestionas nada de la infraestructura; solo usas y configuras.

Existen modelos más recientes como FaaS (Funciones como Servicio, base del serverless) y CaaS (Contenedores como Servicio), que veremos en lecciones posteriores.

El modelo de servicio responde a "qué nivel de abstracción consumo"; el modelo de despliegue responde a "dónde y para quién vive esa nube".

• Nube pública: recursos compartidos del proveedor. Es el modelo más común por su elasticidad y coste.
• Nube privada: infraestructura dedicada (en tu CPD o alojada), habitual en sectores muy regulados como banca o seguros cuando hay requisitos estrictos de soberanía del dato.
• Nube híbrida: combina ambas, por ejemplo manteniendo datos sensibles en privado y desbordando picos de carga a la pública (cloud bursting).
• Multinube: se usan varios proveedores públicos a la vez, para evitar dependencia de uno solo o aprovechar lo mejor de cada uno.

Este es el concepto más importante y peor entendido de la seguridad en la nube. La idea: el proveedor es responsable de la seguridad de la nube (el hardware, la red física, la virtualización) y el cliente es responsable de la seguridad en la nube (sus datos, su configuración, sus accesos). La frontera se mueve según el modelo de servicio.

Explicación del diagrama: a medida que pasamos de IaaS a SaaS, la caja del proveedor crece y la del cliente se reduce. Pero hay una constante: la responsabilidad sobre los datos y el control de accesos casi nunca se delega del todo. En IaaS tú parcheas el sistema operativo; en PaaS lo hace el proveedor; en SaaS gestionas únicamente quién accede y qué datos introduces.

Un error clásico es asumir que "está en la nube, luego es seguro". Si configuras mal un bucket de almacenamiento y lo dejas público, la fuga de datos es responsabilidad tuya, no del proveedor. En sectores regulados (por ejemplo aseguradoras sujetas a normativa como GDPR/LOPDGDD o DORA), entender esta frontera es crítico para el cumplimiento; cualquier diseño concreto debe validarse con el equipo de compliance correspondiente.

Los proveedores organizan su infraestructura física en una jerarquía geográfica:

• Región (region): una zona geográfica amplia (ej. eu-west-1 en Irlanda, eu-south-2 en España). Eliges región por latencia (cercanía a usuarios), soberanía del dato (que los datos no salgan de la UE) y coste (los precios varían por región).
• Zona de disponibilidad (Availability Zone, AZ): dentro de una región hay varias zonas, que son centros de datos físicamente separados pero conectados por red de baja latencia. Sirven para tolerancia a fallos: si una AZ cae (incendio, corte eléctrico), las otras siguen funcionando.
• Edge / puntos de presencia (PoP): ubicaciones cercanas al usuario final para cachear contenido (CDN) y reducir latencia.

Explicación de los comandos:

• aws ec2 describe-regions: pide al proveedor el catálogo de regiones. El parámetro --query filtra la respuesta JSON para mostrar solo el nombre, y --output table la presenta en tabla legible.
• aws ec2 describe-availability-zones --region eu-west-1: lista las zonas dentro de la región de Irlanda. Verás algo como eu-west-1a, eu-west-1b, eu-west-1c. Distribuir tus servidores entre varias AZ es la práctica básica de alta disponibilidad.

La regla de oro de la resiliencia: despliega en al menos dos zonas de disponibilidad para sobrevivir a la caída de un centro de datos, y considera multi-región solo si necesitas recuperación ante desastres a escala geográfica (es más caro y complejo).

• Confundir modelo de servicio con modelo de despliegue. Son ejes ortogonales: puedes tener IaaS en nube privada o SaaS en nube pública. No son lo mismo.
• Creer que "todo lo gestiona el proveedor". El modelo de responsabilidad compartida deja siempre los datos y los accesos de tu lado. Configura cifrado y permisos mínimos.
• Ignorar la región por descuido. Desplegar en EE. UU. datos de clientes europeos puede infringir normativa de protección de datos. Elige región consciente de la soberanía del dato.
• No usar varias zonas de disponibilidad. Un despliegue en una sola AZ no es alta disponibilidad: es un punto único de fallo con factura mensual.
• Subestimar el lock-in. Usar servicios propietarios acelera al principio pero ata a un proveedor. Valora el coste de migrar antes de comprometerte.
• Consejo: empieza por PaaS o servicios gestionados cuando puedas; baja a IaaS solo cuando necesites un control que la plataforma no te da.

1. Una startup quiere lanzar una API web rápido, sin equipo de operaciones, y prefiere no gestionar servidores ni parches. ¿Qué modelo de servicio recomendarías y por qué?
2. Tu empresa almacena datos sensibles de clientes europeos. Explica dos decisiones de diseño relacionadas con regiones y responsabilidad compartida que debas tomar.
3. Clasifica estos servicios en IaaS, PaaS o SaaS: (a) una máquina virtual Linux vacía, (b) Gmail, (c) una plataforma donde subes tu código y se despliega sola.

1. PaaS. Al no tener equipo de operaciones y querer velocidad, lo ideal es subir el código a una plataforma gestionada (tipo App Service, App Engine o Heroku) que se ocupe del sistema operativo, los parches y el escalado. IaaS exigiría administrar servidores; SaaS no aplica porque desarrollan su propio software.
2. (a) Elegir una región dentro de la UE (ej. España o Irlanda) para respetar la soberanía y la normativa de protección de datos, evitando que los datos residan fuera del territorio permitido. (b) Asumir la responsabilidad sobre el cifrado y los controles de acceso, ya que el modelo de responsabilidad compartida deja siempre la protección del dato del lado del cliente; el proveedor solo garantiza la seguridad de la infraestructura. Cualquier decisión concreta debe revisarla el equipo de compliance.
3. (a) IaaS (te dan la infraestructura desnuda), (b) SaaS (aplicación lista para usar), (c) PaaS (plataforma para desplegar tu código).

Hemos visto qué es la nube, sus tres modelos de servicio (IaaS, PaaS, SaaS) y cómo se diferencian por el reparto de gestión, los modelos de despliegue (público, privado, híbrido, multinube), el crítico modelo de responsabilidad compartida y la geografía de regiones y zonas de disponibilidad. Estos fundamentos son la base sobre la que se construye todo lo demás. En la siguiente lección bajaremos un nivel de abstracción para empaquetar y ejecutar aplicaciones de forma portable y reproducible con contenedores y orquestación mediante Docker y Kubernetes.