¿Qué es "la nube"? La infraestructura de otras empresas

Voy a empezar esta lección destruyendo un mito que todavía persiste en 2024: "la nube" no es una entidad mística flotando en el éter digital. No es un concepto abstracto ni una metáfora poética. La nube es, literalmente, el ordenador de otra empresa. Cuando subes un archivo a "la nube", lo que realmente estás haciendo es enviar bytes por internet al disco duro de un servidor que pertenece a Amazon, Microsoft o Google, y que está enchufado a la corriente en un edificio enorme llamado data center. Nada más. Nada menos.

Y te lo digo con la autoridad de alguien que ha estado en ambos lados. He montado racks de servidores a las 3 de la mañana porque un disco se murió en producción. He firmado contratos de leasing de hardware por cientos de miles de euros. Y también he migrado todo eso a AWS en una migración que duró 14 meses y me quitó años de vida. Así que cuando te cuento qué es la nube, te lo cuento desde las trincheras.

### Antes de la nube: cuando las empresas compraban sus propios servidores

Imagina que es 2005. Trabajas en una empresa de e-commerce que crece rápido. Necesitas más capacidad para la base de datos porque el Black Friday te tumbó el año pasado. ¿Qué haces? Primero, convences a tu jefe de que necesitas comprar un servidor nuevo. Segundo, haces un estudio de mercado. Tercero, negocias el contrato y esperas 6-8 semanas a que llegue el hardware. Cuarto, lo montas físicamente en el rack. Quinto, instalas el SO, configuras la red, abres puertos. Sexto, después de 3-4 meses, tienes capacidad nueva. Y eso si todo va bien.

Y aquí viene lo peor: ¿cuánta capacidad compras? Si compras justo lo que necesitas hoy, en 6 meses te quedas corto otra vez. Si compras para 3 años vista, estás pagando hardware que no usarás durante meses. Es como comprar un edificio entero porque necesitas una oficina más grande — sí, tendrás espacio, pero el 80% estará vacío mientras pagas la hipoteca completa. Esto se llamaba "capacity planning" y era una de las decisiones más estresantes en IT.

El mundo on-premise significaba: inversión inicial enorme (CAPEX), tiempos de aprovisionamiento de semanas, hardware que se deprecia desde el día uno, contratos de mantenimiento anuales, equipos de operaciones 24/7, y la horrible sensación de que el viernes a las 11PM algo se iba a romper y te iban a llamar.

### La idea que lo cambió todo: infraestructura como servicio

En 2006, Amazon hizo algo que cambió la industria para siempre. Tenían data centers enormes para operar su tienda online, pero gran parte de esa capacidad estaba ociosa fuera de los picos. Alguien tuvo una idea brillante: ¿y si alquilamos esa capacidad sobrante a otras empresas? Así nació AWS con dos servicios iniciales: S3 (almacenamiento) y EC2 (servidores virtuales). La propuesta era revolucionaria: en vez de comprar un servidor por 50.000€ y esperar 2 meses, alquila uno por 0,10€/hora y tenlo listo en 60 segundos.

El modelo de negocio es idéntico al de un hotel vs comprar un piso. Si viajas a una ciudad 3 noches al año, no compras un apartamento — vas a un hotel, pagas por noche y te vas. Si te mudas permanentemente, comprar sale más barato a largo plazo. La nube es el hotel de la computación.

### Los tres modelos de servicio: IaaS, PaaS, SaaS

1. 01.IaaS (Infrastructure as a Service): te dan el servidor virtual, la red y el disco. Tú instalas todo lo demás. Ejemplo: EC2. Es como alquilar un local vacío.
2. 02.PaaS (Platform as a Service): te dan la plataforma lista para desplegar código. No gestionas el servidor. Ejemplo: AWS Lambda, Glue. Es como alquilar una oficina amueblada.
3. 03.SaaS (Software as a Service): usas la aplicación directamente. No instalas nada. Ejemplo: Gmail, Athena. Es como ir a un coworking.

En ingeniería de datos usamos los tres niveles y uno más. EC2 es IaaS (te dan un servidor virtual, tú instalas todo). EMR es PaaS (te dan un clúster Spark gestionado). Y Lambda, Athena y Glue son serverless: no hay servidor que configurar, pagas por ejecución y AWS se ocupa de todo lo demás. La tendencia clara es moverse hacia arriba: menos gestión de infraestructura, más foco en la lógica de datos.

### ¿Por qué AWS domina en datos?

En 2026, los tres grandes proveedores cloud son AWS (Amazon), Azure (Microsoft) y GCP (Google). AWS tiene ~30% del mercado general, Azure ~21% y Google Cloud ~12% — entre los tres suman el 63% del gasto empresarial en nube. AWS llegó primero (2006 vs Azure 2010 y GCP 2011), tiene el ecosistema más maduro de servicios de datos (S3, Glue, Athena, EMR, Redshift, Kinesis, Lake Formation...), y la mayoría de empresas data-intensive ya están en AWS. Pero la tendencia es clara: AWS sigue primero y pierde puntos cada año mientras Azure y Google los ganan.

Dicho esto, los conceptos son transferibles. Si aprendes S3, entiendes Azure Blob Storage y GCS. Si aprendes IAM de AWS, entiendes RBAC de Azure. Si aprendes Glue, puedes usar Dataflow de GCP. Enseñamos AWS porque es el estándar de facto en datos, pero el 80% de lo que aprendas aplica a cualquier nube. Los conceptos sí son transferibles; el código no. Cuanto más gestionado es un servicio, más dependes de él — y más cuesta salir. Es lo que se llama dependencia del proveedor (vendor lock-in), y es el principal inconveniente estratégico de la nube. Tenlo en cuenta cuando elijas entre un servicio genérico (como Spark sobre EMR) y uno propietario (como Glue ETL): el segundo es más cómodo, pero el día que quieras irte a otra nube, reescribes.

### El mapa de servicios AWS para ingeniería de datos

• ▹S3 (Simple Storage Service): tu data lake. Almacenamiento infinito de objetos.
• ▹IAM (Identity and Access Management): el sistema de llaves y cerraduras. Quién puede acceder a qué.
• ▹Glue: ETL serverless + catálogo de datos. El pegamento que conecta y transforma.
• ▹Athena: SQL directo sobre S3. Consultas ad-hoc sin infraestructura.
• ▹EMR (Elastic MapReduce): clústeres de Spark gestionados. Procesamiento pesado.
• ▹Redshift: data warehouse columnar gestionado. Análisis a escala.
• ▹Lambda: funciones sin servidor. Lógica ligera event-driven.
• ▹Step Functions: orquestador serverless para coordinar workflows.

### Regiones y zonas de disponibilidad

AWS opera en "regiones" repartidas por el mundo: us-east-1 (Virginia), eu-west-1 (Irlanda), eu-south-2 (España)... Cada región es un cluster de data centers independiente. Dentro de cada región hay "zonas de disponibilidad" (AZs) — edificios separados físicamente pero conectados con fibra de baja latencia. Si se incendia un edificio, las otras AZs siguen funcionando.

Para datos personales, la región importa — pero no por el motivo que la gente cree. El RGPD no prohíbe que los datos de europeos salgan de Europa: exige que la transferencia tenga una base legal, y AWS te la da por defecto (sus términos de servicio incluyen las cláusulas contractuales tipo de la Comisión Europea, que se aplican automáticamente a cualquier transferencia fuera del EEE, y desde julio de 2023 hay además decisión de adecuación para EEUU). Lo que sí te va a obligar a quedarte en una región europea es otra cosa: un contrato con un cliente que lo exija, normativa sectorial — sanidad, banca, sector público — o una política interna. Eso se llama residencia de datos, y es un requisito de negocio, no del reglamento. En la práctica, elige región europea cuando alguien te lo exija por escrito, y por latencia; no porque el RGPD lo mande, porque no lo manda.

### Lo que aprenderás en esta skill

Esta es la skill culminante del track. En las próximas 13 lecciones vas a: configurar AWS CLI y LocalStack, dominar S3 como almacenamiento de tu data lake, entender IAM para no dejar puertas abiertas, usar Glue para catalogar y transformar datos, lanzar SQL con Athena directamente sobre S3, gestionar clústeres Spark con EMR, cargar datos en Redshift, crear funciones serverless con Lambda, orquestar pipelines con Step Functions, definir infraestructura como código con Terraform, controlar costes, y construir un pipeline end-to-end completo.