Antes de tocar un solo botón del portal conviene entender qué problema resuelve la nube y por qué una empresa decide mover su plataforma allí. Esta primera lección responde a tres preguntas: qué es la computación en la nube frente a un centro de datos propio, qué es exactamente Microsoft Azure y cuál es su tamaño real, y qué gana —y qué pierde— una organización al adoptarlo. Terminaremos presentando a Contoso Airlines, la aerolínea ficticia que nos acompañará durante todo el curso y cuya plataforma de venta de billetes iremos construyendo pieza a pieza.

Es una lección conceptual, pero no es relleno: casi todos los errores caros que se cometen en Azure (facturas disparadas, arquitecturas rígidas, dependencias imposibles de deshacer) nacen de no haber entendido bien estas ideas al principio.

1. Qué es la computación en la nube
2. El centro de datos propio y sus límites
3. Qué es Microsoft Azure
4. El catálogo de Azure por familias de servicios
5. Ventajas reales de Azure
6. Contrapartidas honestas
7. Azure frente a AWS y Google Cloud
8. El caso Contoso Airlines
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

La computación en la nube consiste en consumir recursos informáticos —servidores, almacenamiento, bases de datos, redes, software— a través de internet y bajo demanda, pagando solo por lo que se usa, en lugar de comprarlos, instalarlos y mantenerlos uno mismo.

La analogía clásica es la electricidad. Una fábrica del siglo XIX necesitaba su propia caldera y su propio generador: capital inmovilizado, personal de mantenimiento y una capacidad fija que sobraba de noche y faltaba en los picos. Hoy nadie genera su propia electricidad: se conecta a la red, consume lo que necesita en cada momento y recibe una factura proporcional. La nube hace exactamente eso con la capacidad de cómputo.

De esa idea se derivan cinco características que la definen formalmente:

Existen además tres formas de desplegar la nube:

• Nube pública: la infraestructura pertenece al proveedor (Azure, AWS, Google Cloud) y se comparte entre clientes. Es lo que veremos en este curso.
• Nube privada: infraestructura dedicada a una sola organización, en sus instalaciones o alojada por un tercero.
• Nube híbrida: combinación de ambas, con conectividad entre ellas. Es el escenario más habitual en empresas con historia, y también el de Contoso Airlines durante la migración.

Para valorar la nube hay que entender qué duele en el modelo tradicional. Contoso Airlines tiene hoy dos salas de servidores, una en la oficina de Barcelona y otra en la de Palma. Estos son sus problemas reales:

• Compra por el pico, uso por el valle. El servidor de la web se dimensionó para el "Black Friday del vuelo" de noviembre. Once meses al año está al 12 % de CPU, pero se paga entero.
• Plazos de aprovisionamiento. Añadir dos servidores nuevos implica petición, presupuesto, aprobación, pedido, entrega, racking e instalación: entre seis y diez semanas. El negocio quiere lanzar una campaña en dos.
• CAPEX frente a OPEX. Se inmoviliza capital en hardware que se amortiza a cinco años y queda obsoleto antes.
• Mantenimiento invisible. Parches, discos que fallan, SAI, refrigeración, licencias, renovación de certificados. Trabajo que no diferencia a la empresa frente a su competencia.
• Recuperación ante desastres teórica. Existe un plan en un documento, pero nunca se ha probado una conmutación completa entre Barcelona y Palma porque implicaba duplicar la inversión.
• Alcance geográfico. Un cliente que compra desde México sufre la latencia de cruzar el Atlántico hasta Barcelona en cada clic.

La nube no elimina el trabajo, lo desplaza: deja de haber discos que cambiar y empieza a haber arquitecturas que diseñar, costes que gobernar e identidades que proteger. Eso es exactamente lo que aprenderás en este curso.

Microsoft Azure es la plataforma de nube pública de Microsoft: un conjunto de más de doscientos servicios que se despliegan sobre una red mundial de centros de datos propiedad de Microsoft, y que se consumen mediante un plano de control común (portal web, línea de comandos, API y SDK).

Tres ideas que conviene fijar desde el principio:

1. Azure es infraestructura física real. Cuando creas una máquina virtual, se reserva capacidad en un servidor concreto de un edificio concreto. La abstracción es buena, pero la física sigue existiendo: por eso importan las regiones y las zonas de disponibilidad (lección 01-02).
2. Todo pasa por Azure Resource Manager. Da igual que uses el portal, la CLI o una plantilla: todos hablan con la misma API de gestión. Lo veremos en detalle en la lección 01-05.
3. Los servicios son piezas componibles. Azure no es "un producto", es un catálogo. El valor está en elegir bien las piezas y conectarlas.

En cuanto a magnitud: Azure opera en más de 60 regiones repartidas por decenas de países, con presencia en los cinco continentes, y es una de las tres grandes nubes públicas junto con AWS y Google Cloud. Las cifras exactas de regiones y servicios cambian cada trimestre, así que conviene consultarlas siempre en la documentación oficial en lugar de fiarse de un número memorizado.

Ver doscientos servicios en una lista es abrumador. Ver seis familias es manejable. Esta tabla es el mapa mental del curso completo: cada familia corresponde, a grandes rasgos, a uno o varios módulos.

Un consejo de método: nunca aprendas un servicio "porque existe". Aprende el problema y busca después qué servicio lo resuelve. Todo el curso está construido así.

• Elasticidad. La capacidad sigue a la demanda. Contoso puede pasar de 2 a 20 instancias de su web durante la campaña de octubre y volver a 2 en noviembre, automáticamente (módulo 2).
• Pago por uso. No hay compra de hardware. Se paga por hora de máquina encendida, por GB almacenado o por petición atendida. El corolario incómodo: lo que se olvida encendido también se paga.
• Alcance global. Desplegar en Brasil o Japón es cambiar un parámetro de región, no abrir una delegación. Con servicios de entrega global se sirve contenido cerca del usuario final.
• Seguridad y cumplimiento como base. Microsoft mantiene certificaciones (ISO 27001, SOC 1/2/3, PCI DSS, ENS en España, entre muchas otras) sobre la infraestructura, y aporta herramientas de cifrado, identidad y auditoría. Ojo: la certificación del proveedor no certifica tu aplicación; hay un modelo de responsabilidad compartida que veremos en 01-02.
• Recuperación ante desastres asequible. Replicar datos a otra región es una opción de configuración, no un segundo centro de datos.
• Integración con el ecosistema Microsoft. Si la empresa ya usa Microsoft 365, Windows Server, SQL Server o Active Directory, la continuidad es real: identidades federadas con Microsoft Entra ID, licencias reutilizables con Azure Hybrid Benefit (módulo 8) y herramientas familiares.
• Innovación sin inversión previa. Probar un servicio de IA cuesta unos céntimos y una tarde, no un proyecto de un año.

Un curso que solo cuenta las ventajas no sirve para tomar decisiones. Estas son las contrapartidas reales:

• Dependencia del proveedor (vendor lock-in). Cuanto más específico es el servicio (Cosmos DB, Logic Apps, Functions), más difícil es marcharse. Mitigación razonable: usar estándares abiertos donde el coste de hacerlo sea bajo (contenedores, PostgreSQL, Terraform/Bicep) y aceptar conscientemente el acoplamiento donde el beneficio lo justifique.
• Coste descontrolado si no se gobierna. La facilidad de crear recursos es también la facilidad de crear gasto. Entornos de prueba olvidados, discos huérfanos de máquinas borradas, niveles de servicio sobredimensionados. Por eso el módulo 8 es un módulo entero y por eso en la lección 01-03 crearemos un presupuesto antes de crear nada más.
• Curva de aprendizaje. Hay que aprender identidad, redes, costes y automatización. Un administrador de sistemas experto en VMware no es automáticamente productivo en Azure el primer día.
• Menos control fino. No eliges el modelo exacto de CPU ni entras en la sala. Para cargas con requisitos muy peculiares (hardware especializado, licencias atadas a la máquina física) puede ser un problema.
• Dependencia de la conectividad. Si cae la línea de la oficina, la nube sigue funcionando, pero tú no llegas a ella.
• Soberanía del dato. Almacenar datos personales de clientes europeos implica decisiones de región y contratos. Lo tratamos en 01-02.
• Los precios y los servicios cambian. Nombres, niveles y tarifas se revisan con frecuencia. Comprueba siempre en la documentación y en la calculadora oficial antes de comprometerte.

Comparación breve y honesta, sin entrar en guerras de religión. Las tres son plataformas maduras y con cualquiera de ellas se puede construir la solución de Contoso.

Por qué elige Azure Contoso Airlines: ya usa Microsoft 365 para el correo corporativo, tiene Active Directory en sus oficinas y sus sistemas de reservas corren sobre SQL Server con licencias vigentes. La continuidad de identidad y el aprovechamiento de licencias inclinan la balanza. No es una verdad universal: es una decisión razonada en un contexto concreto, que es exactamente como deben tomarse estas decisiones.

Contoso Airlines es una aerolínea ficticia de tamaño medio con base en el Mediterráneo, unos 40 aviones y venta directa a través de su web. Nos servirá de hilo conductor durante todo el curso.

• Dos salas de servidores: Barcelona (principal) y Palma (secundaria, poco más que una copia de seguridad).
• La web de venta de billetes corre sobre dos servidores físicos con un balanceador antiguo.
• El motor de disponibilidad y precios es una aplicación interna acoplada a la web.
• La base de datos de reservas está en SQL Server, con copia nocturna a cinta.
• Las tarjetas de embarque en PDF se guardan en un recurso compartido de red que ya va por el tercer disco lleno.
• El personal de tierra usa una aplicación de escritorio para consultar operaciones, que solo funciona dentro de la red corporativa.
• En temporada alta y en campañas puntuales, la web se degrada y se pierden ventas.

• Marta Ríos, responsable de infraestructura. Le preocupa la disponibilidad, la seguridad y no perder el control.
• Diego Salas, desarrollador backend. Quiere desplegar sin depender de nadie y dejar de configurar servidores a mano.
• Nuria Peña, responsable financiera. Aparecerá en el módulo 8 y hará la pregunta correcta: "¿cuánto nos está costando esto exactamente y por qué?".

A lo largo del curso montaremos, pieza a pieza, esta plataforma:

• Contoso Reservas: la aplicación web pública de venta de billetes.
• API de Disponibilidad: servicio interno que consulta plazas y precios.
• Base de datos de reservas gestionada, con copias automáticas.
• Almacenamiento de tarjetas de embarque en PDF.
• Panel de operaciones para el personal de tierra.

Este diagrama es deliberadamente de alto nivel: todavía no dice si la web será una máquina virtual o un servicio gestionado, ni en qué región vivirá. Esas decisiones son precisamente el contenido de las lecciones siguientes.

• Creer que "migrar a la nube" es copiar los servidores tal cual. Levantar las mismas máquinas en Azure (lift and shift) es una opción legítima como primer paso, pero si te quedas ahí pagas la nube sin obtener sus ventajas. Lo veremos en el módulo 9.
• Empezar creando recursos antes de entender la facturación. El orden correcto es: entender el modelo, crear la cuenta con un presupuesto y una alerta, y solo entonces desplegar. Es el orden de este módulo, y no es casualidad.
• Confundir "seguro por defecto" con "seguro". Que Microsoft certifique sus centros de datos no significa que tu cuenta de almacenamiento abierta al público sea segura.
• Memorizar cifras. El número de regiones, los precios y los nombres comerciales cambian. Memoriza conceptos y consulta cifras.
• Consejo de vocabulario. Usa la terminología actual: Microsoft Entra ID (antes Azure AD), Microsoft Defender for Cloud (antes Security Center) y Azure AI Services (antes Cognitive Services). Encontrarás mucha documentación antigua con los nombres viejos.
• Consejo económico. Todavía no hemos creado nada, así que aún no gastas nada. A partir de la lección 01-03 sí: cada recurso encendido cuesta dinero real. Adquiere ya el hábito de apagar o borrar lo que dejes de usar.

Enumera cinco problemas concretos del centro de datos actual de Contoso Airlines e indica, para cada uno, qué característica de la computación en la nube lo aborda (autoservicio, elasticidad, servicio medido, acceso por red o agrupación de recursos).

Para cada una de estas tres decisiones de Contoso, escribe una ventaja y una contrapartida honesta:

1. Sustituir el recurso compartido de red de las tarjetas de embarque por almacenamiento de objetos en Azure.
2. Usar un servicio de base de datos gestionado en lugar de instalar SQL Server en una máquina virtual.
3. Elegir Azure en lugar de AWS.

Clasifica estos elementos de la plataforma objetivo de Contoso en las familias de servicios de la tabla del apartado 4: la aplicación web pública, los PDF de las tarjetas de embarque, el aislamiento de la API interna, la base de datos de reservas, el control de quién accede al panel de operaciones y las alertas cuando la web responde lenta.

Solución 1 (propuesta, admite variantes):

Solución 2 (propuesta):

1. Almacenamiento de objetos: ventaja, capacidad prácticamente ilimitada, con redundancia y coste por GB, sin discos que ampliar; contrapartida, la aplicación debe reescribirse para hablar con una API en lugar de con una ruta de red, y hay que vigilar los permisos de acceso público.
2. Base de datos gestionada: ventaja, copias, parches y alta disponibilidad los gestiona la plataforma; contrapartida, se pierde acceso al sistema operativo y a ciertas configuraciones avanzadas, y el coste es mayor que el de una VM equivalente sin gestionar.
3. Elegir Azure: ventaja, continuidad de identidad con el Active Directory y Microsoft 365 existentes, y aprovechamiento de licencias; contrapartida, mayor dependencia de un solo proveedor y de su hoja de ruta.

Solución 3:

La computación en la nube sustituye la compra de capacidad por el consumo de capacidad, y con ello resuelve los tres dolores clásicos del centro de datos propio: sobredimensionar para el pico, tardar semanas en crecer y mantener infraestructura que no diferencia al negocio. Microsoft Azure es la propuesta de Microsoft para ese modelo: un catálogo enorme organizado en familias (cómputo, almacenamiento, red, datos, identidad, DevOps, IA y gestión), desplegado sobre una red mundial de centros de datos. Sus ventajas —elasticidad, pago por uso, alcance global e integración con el ecosistema Microsoft— son reales, y también lo son sus contrapartidas: dependencia del proveedor, coste descontrolado sin gobierno y una curva de aprendizaje seria.

Hemos conocido a Contoso Airlines, su punto de partida y la plataforma que construiremos juntos. La siguiente pregunta es inevitable: cuando Contoso mueva su web a Azure, ¿la pone en una máquina virtual que administra ella o en un servicio gestionado? ¿Y en qué punto del planeta vive esa web? Eso es exactamente lo que resolveremos en la siguiente lección, Modelos de servicio, regiones y zonas de disponibilidad, donde veremos IaaS, PaaS, SaaS y serverless, el modelo de responsabilidad compartida y cómo se elige dónde desplegar.