Implementación y administración de recursos de proceso
Este módulo cubre los servicios de cómputo de Azure: cómo crear y dimensionar máquinas virtuales, garantizar su disponibilidad, desplegar aplicaciones web con App Service y trabajar con contenedores.
Máquinas virtuales de Azure
Lista de comprobación antes de crear una VM
Crear una VM en Azure no es simplemente pulsar un botón. Hay decisiones que conviene tomar antes para no tener que rehacerlo todo después:
Red — Lo primero y más importante. Diseña la red antes de crear nada. Las redes virtuales (VNet), subredes y rangos de IP son difíciles de cambiar una vez configurados. Piensa en qué servicios necesitan comunicarse entre sí y si hay que conectar con la red local (on-premises).
Para proteger el tráfico entre subredes usa Grupos de seguridad de red (NSG): actúan como firewalls de software que filtran tráfico entrante y saliente a nivel de interfaz de red y subred.
Nombre — El nombre de la VM se convierte en el nombre del equipo dentro del SO y en el nombre del recurso en Azure. Difícil de cambiar después. Usa una convención que incluya entorno, región, rol e instancia. Ejemplo: prodeus-webvm01 (producción, East US, servidor web, instancia 01).
Región — Elige la región más cercana a los usuarios para reducir latencia. Ten en cuenta que no todos los tamaños de VM están disponibles en todas las regiones, y los precios varían entre regiones.
Tamaño — Azure ofrece familias de VM según la carga de trabajo:
| Familia | Relación | Cuándo usarla |
|---|---|---|
| Uso general | CPU/memoria equilibrada | Desarrollo, BBDDs pequeñas, servidores web ligeros |
| Optimizada para cómputo | CPU alta | Servidores web de alto tráfico, procesamiento por lotes |
| Optimizada para memoria | Memoria alta | Bases de datos relacionales, cachés, análisis en memoria |
| Optimizada para almacenamiento | I/O alta | Bases de datos con muchas operaciones de disco |
| GPU | Gráficos/IA | Renderizado, entrenamiento de modelos de ML |
| Alto rendimiento | CPU máxima + red rápida | HPC, simulaciones científicas |
💡 Puedes cambiar el tamaño de una VM en caliente si el nuevo tamaño está disponible en el mismo clúster de hardware. Si no, hay que detener y desasignar la VM primero (esto sí permite cualquier tamaño disponible en la región).
Discos de una VM
Toda VM tiene al menos dos discos: el de SO y un disco temporal. Los datos de aplicación deben ir en discos adicionales independientes, así puedes desasociarlos y reasignarlos si la VM falla.
Tipos de disco de mejor a peor rendimiento:
| Tipo | Caso de uso |
|---|---|
| Ultra Disk | SAP HANA, Oracle, SQL de misión crítica |
| SSD Premium v2 | Producción con alta carga de I/O |
| SSD Premium | Producción general sensible al rendimiento |
| SSD Estándar | Servidores web, entornos de dev/test |
| HDD Estándar | Backups, datos de acceso poco frecuente |
⚠️ Ultra Disk y SSD Premium v2 no pueden usarse como disco del SO, solo como discos de datos.
Modelo de precios
Los costes de una VM tienen dos componentes independientes:
Cómputo — Se factura por minuto. Se para cuando desasignas la VM (no cuando la “paras” sin desasignar). Dos opciones de pago:
- Pago por uso: flexible, sin compromiso, ideal para cargas variables o temporales
- Instancias reservadas: compromiso de 1 o 3 años, hasta un 72% de descuento. Ideal para VMs que corren continuamente
Almacenamiento — Se cobra siempre, incluso cuando la VM está parada o desasignada. Los discos existen aunque la VM no esté corriendo.
Opciones para crear y gestionar VMs
| Herramienta | Cuándo usarla |
|---|---|
| Azure Portal | Primeras pruebas, operaciones puntuales |
| CLI de Azure | Scripts en Linux/macOS, automatización multiplataforma |
| Azure PowerShell | Scripts en Windows, automatización de tareas repetidas |
| Plantillas ARM / Bicep | Infraestructura como código, despliegues reproducibles |
| Terraform | IaC multi-cloud con HCL |
| SDK (C#, Python, Java…) | Gestión de VMs dentro de una aplicación |
| Extensiones de VM | Configuración e instalación de software post-despliegue |
| Azure Automation | Automatización de mantenimiento: actualizaciones, configuración, monitorización |
Disponibilidad de máquinas virtuales
Tipos de interrupciones
Azure distingue tres tipos de eventos que pueden afectar a una VM:
-
Mantenimiento no planeado: el hardware está a punto de fallar. Azure usa migración en vivo para mover la VM a un servidor sano con una pausa mínima.
-
Tiempo de inactividad inesperado: fallo imprevisto de hardware (disco, red, alimentación). Azure mueve la VM automáticamente, pero hay un reinicio.
-
Mantenimiento planeado: Microsoft actualiza la plataforma. Se hace de forma escalonada para minimizar el impacto.
Conjuntos de disponibilidad
Agrupación lógica de VMs que garantiza que no todas se vean afectadas por el mismo evento de mantenimiento o fallo de hardware. Azure distribuye las VMs del conjunto entre dominios de error y dominios de actualización.
-
Dominio de error: grupo de VMs que comparten el mismo bastidor físico (fuente de alimentación, switches). Máximo 2 dominios de error por defecto. Protege contra fallos de hardware físico.
-
Dominio de actualización: grupo de VMs que se reinician juntas durante el mantenimiento planeado. De 1 a 20 dominios (5 por defecto). Solo se reinicia un dominio de actualización a la vez.
💡 Una VM solo puede añadirse a un conjunto de disponibilidad en el momento de su creación. No se puede cambiar después sin recrear la VM.
Buenas prácticas con conjuntos de disponibilidad:
- Coloca cada capa de la aplicación (web, app, BBDD) en su propio conjunto de disponibilidad
- Combínalos con Azure Load Balancer para distribuir el tráfico
Zonas de disponibilidad
Llevan la protección un nivel más arriba: cada zona es un datacenter físicamente separado dentro de la misma región, con energía, red y refrigeración independientes. Hay mínimo 3 zonas por región habilitada.
Diferencia clave respecto a los conjuntos de disponibilidad:
- Conjuntos de disponibilidad: protegen contra fallos dentro de un datacenter
- Zonas de disponibilidad: protegen contra la caída de un datacenter completo
Escalado: vertical vs horizontal
Escalado vertical (scale up/down): cambiar el tamaño de la VM. Más sencillo pero requiere reinicio y tiene límite de hardware.
Escalado horizontal (scale out/in): añadir o quitar instancias de VM. Más flexible, sin límite práctico, no requiere reinicio. Es la opción recomendada para cargas variables en producción.
Virtual Machine Scale Sets (VMSS)
Permiten crear y gestionar un grupo de VMs idénticas que escalan automáticamente según la demanda. No hay que aprovisionar las VMs por adelantado.
Características principales:
-
Dos modos de orquestación: Uniforme (todas idénticas) y Flexible (pueden variar entre sí). El modo flexible es el recomendado para nuevas implementaciones.
-
Compatible con Azure Load Balancer (capa 4) y Azure Application Gateway (capa 7)
-
El escalado automático se configura con reglas basadas en métricas (CPU, memoria) o en programación horaria
Parámetros de escalado automático a configurar:
- Número mínimo, máximo y predeterminado de instancias
- Umbral de CPU para escalar hacia fuera (añadir instancias)
- Umbral de CPU para escalar hacia dentro (eliminar instancias)
- Duración de la consulta de métricas (para estabilizar antes de actuar)
Continuidad de negocio y backup
Azure Site Recovery: replica VMs completas a una región secundaria. Si la región principal cae, puedes hacer failover a la secundaria en minutos. También sirve para probar planes de recuperación ante desastres sin afectar producción.
Azure Backup: copia de seguridad como servicio. Guarda los datos en un almacén de Recovery Services. Soporta VMs Windows y Linux, SQL Server, SharePoint, Exchange y ficheros. Ventajas clave: sin límite de retención, cifrado de datos, copias coherentes con la aplicación y sin coste por la transferencia de datos.
Azure App Service
¿Qué es App Service?
Plataforma como servicio (PaaS) para hospedar aplicaciones web, APIs REST y backends móviles sin gestionar servidores. Soporta .NET, Java, Node.js, Python y PHP en Windows y Linux.
Ventajas principales:
- Integración CI/CD con GitHub, Azure DevOps, Bitbucket y Docker Hub
- Escalado automático horizontal y vertical
- Certificados SSL, autenticación integrada y cumplimiento normativo (ISO, SOC, PCI)
- Visual Studio y VS Code integrados
Planes de App Service
El plan determina los recursos (CPU, RAM) y las funcionalidades disponibles. Los niveles son: Free, Shared, Basic, Standard, Premium e Isolated. A partir de Standard se pueden usar slots de despliegue.
Slots de despliegue
Un slot es una instancia paralela de la aplicación con su propio hostname. Permiten:
- Desplegar en staging y validar antes de pasar a producción
- Hacer swap (intercambio) entre slots sin tiempo de inactividad: las instancias ya están calientes cuando se intercambian
- Revertir al estado anterior haciendo el swap inverso
La configuración se divide en dos tipos:
-
Intercambiable: pasa de un slot al otro al hacer swap (código, extensiones, cadenas de conexión marcadas como no específicas de slot…)
-
Específica del slot: permanece en el slot aunque se haga swap (nombre de dominio personalizado, certificados, configuración de escala…)
Dominios personalizados
Por defecto App Service asigna un subdominio de azurewebsites.net. Para usar tu propio dominio:
- Reserva el dominio (puedes hacerlo desde el Portal de Azure)
- Crea un registro DNS: CNAME (para subdominios, apunta al nombre de Azure) o A (para el dominio raíz, apunta a la IP de Azure)
- Valida y añade el dominio en el Portal
💡 Prefiere CNAME cuando sea posible: si cambia la IP de Azure, el CNAME sigue funcionando. Un registro A requeriría actualización manual.
Seguridad y autenticación
App Service tiene un módulo de autenticación y autorización integrado que se ejecuta antes de que llegue el código de la aplicación. No requiere cambios en el código.
Soporta Microsoft Entra ID, Google, Facebook y X (Twitter). Dos modos:
- Permitir solicitudes anónimas: el código de la aplicación gestiona la autenticación
- Solo solicitudes autenticadas: redirige automáticamente a login; sin código necesario
Application Insights
Extensión de Azure Monitor para supervisar aplicaciones en tiempo real. Detecta anomalías automáticamente y permite analizar tasas de solicitud, tiempos de respuesta, errores, dependencias externas, excepciones y rendimiento de carga de páginas. Útil para correlacionar problemas con despliegues recientes.
Contenedores en Azure
VM vs Contenedor
| VM | Contenedor | |
|---|---|---|
| Aislamiento | SO completo independiente | Comparte el kernel del SO host |
| Tamaño | Gigabytes | Megabytes |
| Arranque | Minutos | Segundos |
| SO | Propio completo | Modo usuario del SO |
| Gestión | Hyper-V, VMware | Docker, Kubernetes |
| Tolerancia a fallos | Failover a otro servidor | El orquestador recrea el contenedor en segundos |
Los contenedores son ideales cuando necesitas desplegar muchas instancias pequeñas rápidamente, o cuando quieres garantizar que la aplicación se comporta igual en desarrollo, staging y producción.
Azure Container Instances (ACI)
La forma más rápida de correr un contenedor en Azure sin gestionar infraestructura. Sin VMs, sin Kubernetes, sin configuración de clústeres.
Características:
- Arranque en segundos
- IP pública y nombre DNS configurables
- CPU y memoria asignables por contenedor (0,1-4 vCPU, 0,1-16 GB)
- Soporta contenedores Linux y Windows
- Puede montar Azure Files para almacenamiento persistente
- Despliegue en VNet para comunicación privada
Grupos de contenedores: varios contenedores que comparten host, IP, ciclo de vida y volúmenes. Similar a un pod de Kubernetes. Se definen con plantillas ARM, Bicep o YAML.
Casos de uso típicos para grupos multicontenedor: app web + sidecar de logs, app + contenedor de monitorización, frontend + backend en el mismo grupo.
⚠️ ACI es ideal para tareas aisladas, de corta duración o lotes. Para microservicios a largo plazo, considera Container Apps o AKS.
Azure Container Apps (ACA)
Plataforma serverless para microservicios y aplicaciones basadas en eventos. Construida sobre Kubernetes internamente, pero sin exponer su complejidad.
Escala automáticamente en función de tráfico HTTP, eventos (colas, mensajes), CPU/memoria o reglas KEDA. Puede escalar hasta cero instancias cuando no hay tráfico.
Diferencias clave respecto a ACI y AKS:
| ACI | Container Apps | AKS | |
|---|---|---|---|
| Complejidad | Mínima | Media | Alta |
| Casos de uso | Tareas cortas, aisladas | Microservicios, APIs, eventos | Orquestación compleja |
| Control Kubernetes | Ninguno | Abstraído | Completo |
| Escalado automático | No | Sí (hasta cero) | Sí |
| Gestión de infraestructura | Nula | Nula | Parcial (nodos gestionados) |
Resumen del módulo 4
| Concepto | Clave |
|---|---|
| Planificación de red | Diseñar VNet y subredes antes de crear VMs; difícil de cambiar después |
| NSG | Firewall de software a nivel de subred e interfaz de red |
| Tamaños de VM | Elegir según carga: uso general, cómputo, memoria, almacenamiento, GPU |
| Discos | SO + temporal incluidos; añadir discos de datos para la aplicación |
| Pago por uso vs RI | RI: hasta 72% de descuento para VMs que corren continuamente |
| Conjuntos de disponibilidad | Dominios de error (hardware) + dominios de actualización (mantenimiento planeado) |
| Zonas de disponibilidad | Protección a nivel de datacenter completo dentro de una región |
| VMSS | Escalado automático de grupos de VMs idénticas |
| Escalado horizontal | Añadir/quitar instancias; más flexible y sin límite que el vertical |
| Azure Backup | Backup como servicio con almacén de Recovery Services; sin límite de retención |
| Azure Site Recovery | Replicación y failover entre regiones para continuidad de negocio |
| App Service | PaaS para web, APIs y móvil; sin gestionar servidores |
| Slots de despliegue | Entornos paralelos para validar antes de pasar a producción con swap sin downtime |
| ACI | Contenedores aislados sin infraestructura; arranque en segundos |
| Container Apps | Microservicios serverless con escalado automático hasta cero |
| AKS | Kubernetes gestionado para orquestación compleja; máximo control |