AZ-900
Deep Dive
VMs, App Service, Containers, Functions y cuándo usar cada uno. El dominio de cómputo representa ~20% del AZ-900. La clave es saber elegir el servicio correcto para cada escenario.
Contenido
Componentes de una VM
Compute (vCPU + RAM)
El "cerebro". Medido en vCPUs y GB de RAM. Define el tamaño de la VM (ej: Standard_D4s_v3 = 4 vCPU, 16 GB RAM).
OS Disk (Managed Disk)
El disco del sistema operativo. Siempre presente. Premium SSD = más rápido. Standard HDD = más barato.
Data Disks
Discos adicionales para datos. Una VM puede tener múltiples data disks. Cada disco = Managed Disk separado.
Network Interface Card (NIC)
La tarjeta de red virtual. Conecta la VM a una VNet/Subnet. Una VM puede tener múltiples NICs.
Public IP (opcional)
Dirección IP pública para acceso desde internet. Sin ella, la VM solo es accesible desde dentro de la VNet.
Tipos de disco para VMs
| Tipo | IOPS máx | Latencia | Uso |
|---|---|---|---|
| Ultra Disk | 160,000+ | < 1ms | DB críticas, SAP HANA |
| Premium SSD v2 | 80,000 | < 2ms | DB producción general |
| Premium SSD | 20,000 | < 5ms | Apps de producción |
| Standard SSD | 6,000 | < 10ms | Web servers, dev/test |
| Standard HDD | 500 | < 20ms | Backups, archivos |
VM Scale Sets (VMSS)
Grupo de VMs idénticas con auto-scaling automático. Define imagen, tamaño y reglas de escala (CPU > 70% → +1 VM, CPU < 20% → -1 VM).
El nombre de la VM (ej: Standard_D4s_v3) codifica su familia, versión y capacidades.
Serie B
Burstable
CPU basal baja, acumula créditos cuando está idle y los usa en picos. Ideal para workloads intermitentes.
Uso ideal
Dev/Test, web servers con poco tráfico, CI/CD agents
Serie D
General Purpose
Equilibrio entre CPU y memoria. La familia más versátil. La "default" para la mayoría de workloads.
Uso ideal
Apps web, bases de datos medianas, backends API
Serie F
Compute Optimized
Mayor relación CPU/RAM. Para workloads que necesitan mucha CPU con poco RAM.
Uso ideal
Gaming servers, simulaciones, procesamiento batch intensivo
Serie E
Memory Optimized
Alto ratio de RAM por vCPU. Para workloads que necesitan mucha memoria.
Uso ideal
SAP HANA, Redis in-memory, SQL Server con bases grandes
Serie N
GPU
GPUs NVIDIA. Para procesamiento paralelo masivo.
Uso ideal
ML training, inferencia IA, renderizado 3D, simulaciones científicas
Serie L
Storage Optimized
Alto I/O de disco. NVMe SSDs locales de altísima velocidad (efímeros).
Uso ideal
Cassandra, Elasticsearch, grandes volúmenes de datos transaccionales
Cómo leer el nombre de una VM
Standard
Tier (Basic/Standard)
D
Familia (General Purpose)
4
Número de vCPUs
s
Premium Storage soportado
v3
Versión de la generación
| Tier | RAM/CPU | Custom Domain | Slots | Auto-scale | VNet | Uso |
|---|---|---|---|---|---|---|
| Free | 1 GB / 1 CPU | ✗ | 0 | ✗ | ✗ | Demo/prueba rápida |
| Shared | 1 GB / 1 CPU | ✓ | 0 | ✗ | ✗ | Dev personal |
| Basic | 1.75–7 GB | ✓ | 0 | Manual | ✗ | Dev/Test con tráfico bajo |
| Standard | 1.75–7 GB | ✓ | 5 | Auto | ✗ | Producción pequeña-mediana |
| Premium | 3.5–32 GB | ✓ | 20 | Auto+Zone | ✓ | Producción con aislamiento de red |
| Isolated | 3.5–32 GB | ✓ | 20 | Auto | Dedicada | Compliance estricto, red aislada (ASE) |
Deployment Slots — zero-downtime deployments
Los Slots son entornos separados dentro del mismo App Service Plan. Cada slot tiene su propia URL (myapp-staging.azurewebsites.net). Puedes hacer swap entre slots de forma atómica — sin downtime.
1. Deploy a Staging
Nueva versión va al slot Staging. URL de staging para QA. Producción no se toca.
2. Smoke test en Staging
QA verifica en staging.azurewebsites.net. Si hay problemas, se arreglan sin afectar prod.
3. Swap slots
Staging ↔ Producción en segundos. Sin downtime. Rollback = otro swap.
Azure Container Instances (ACI)
Containers serverless: sin gestionar VMs ni orquestación. Carga una imagen Docker y corre. Facturación por segundo de CPU y GB de RAM usados.
ACI = simple y rápido. No es para producción a escala.
Azure Kubernetes Service (AKS)
Kubernetes gestionado. Microsoft gestiona el control plane (kube-apiserver, etcd). Tú gestionas los nodos worker (VMs).
AKS = para producción a escala con microservicios.
ACI vs AKS — cuándo elegir cada uno
| Dimensión | ACI | AKS |
|---|---|---|
| Complejidad | Mínima | Alta (Kubernetes es complejo) |
| Escala | Limitada (manual) | Ilimitada (auto-scale) |
| Costo base | $0 (paga por uso) | VMs de nodos siempre corriendo |
| Durabilidad | Efímero (tasks) | Persistente (servicios long-running) |
| Networking | Simple | Avanzado (Ingress, Service Mesh) |
Azure Functions — código serverless
Ejecutas código en respuesta a eventos. Sin gestionar servidores. Paga por ejecución (o tiempo CPU).
Triggers principales
Planes de hosting
Azure Logic Apps — flujos sin código
Automatización de flujos de trabajo visualmente, sin escribir código. Conectores para cientos de servicios (Office 365, Salesforce, SAP, etc.).
Caso de uso típico
vs Azure Functions
Functions = código. Logic Apps = visual/sin código. Ambas son serverless.
+300 conectores
SAP, Salesforce, Twitter, SQL, SharePoint, Teams, etc.
Azure Batch
Procesamiento batch a escala masiva. Provisiona automáticamente un pool de VMs, ejecuta trabajos en paralelo, escala a miles de cores, y libera las VMs al terminar.
Azure CycleCloud (HPC)
Orquestación de clusters HPC tradicionales (MPI, SLURM, PBS) en Azure. Para científicos e ingenieros que ya tienen workloads HPC.
¿Necesitas control del SO o licensing especial?
¿Es una app web/API o backend?
¿Tienes múltiples microservicios con necesidades distintas de escala?
¿Es un task corto o job en respuesta a un evento?
¿Es un flujo de integración/automatización sin código?
¿Es procesamiento batch masivo paralelo?
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
¿Qué servicio de Azure permite ejecutar contenedores de forma rápida sin necesidad de gestionar un clúster de orquestación?