Diseñar la capa de aplicación: dimensionar App Service correctamente, aplicar los patrones cloud que el examen referencia (retry, circuit breaker, CQRS, strangler fig), y externalizar configuración, estado y cache.
Contenido
| Tier | Aporta | Cuándo |
|---|---|---|
| Free / Shared | Compute compartido, sin SLA ni custom domain SSL | Pruebas |
| Basic | Compute dedicado, custom domains, escala manual a 3 | Dev/test y apps pequeñas |
| Standard | Autoscale (10), slots (5), backups diarios | Producción general |
| Premium v3/v4 | Más slots (20), 30 instancias, VNet integration, zone redundancy, mejor hardware | Producción exigente; "VNet integration" o "zone redundancy" → mínimo Premium |
| Isolated v2 (ASE v3) | App Service Environment: despliegue EN tu VNet, single-tenant, hasta 100 instancias | Aislamiento total de red/compliance — la señal es "completamente aislado en la VNet" |
Deployment slots
Networking de App Service
| Patrón | Problema que resuelve | En Azure |
|---|---|---|
| Retry con backoff | Fallos transitorios de red/servicio | SDKs de Azure lo traen; Polly en .NET |
| Circuit Breaker | No martillear un servicio caído; fallar rápido | Lógica de app / API Management |
| Queue-Based Load Leveling | Picos que tumban al backend — la cola amortigua | Service Bus / Storage Queues entre web y worker |
| Competing Consumers | Procesar la cola en paralelo escalando workers | Functions/Container Apps escalando por longitud de cola |
| CQRS | Separar modelos de lectura y escritura para escalar cada uno | Escrituras a SQL, lecturas desde réplicas/cache/Cosmos |
| Event Sourcing | Historial completo como secuencia de eventos | Cosmos change feed / Event Hubs |
| Saga | Transacciones distribuidas entre microservicios (compensación) | Durable Functions, Service Bus |
| Strangler Fig | Migrar un monolito incrementalmente, ruta a ruta | API Management / App Gateway enrutando entre legacy y nuevo |
| Sidecar / Ambassador | Funcionalidad transversal junto al contenedor | Dapr en Container Apps / AKS |
| Cache-Aside | Aliviar la DB con cache de lectura | Azure Cache for Redis |
Señales típicas
"Los picos de pedidos saturan el backend" → cola entre capas (load leveling). "Migrar el monolito gradualmente sin big bang" → strangler fig. "Las lecturas superan 100:1 a las escrituras" → CQRS + cache/réplicas.
App Configuration
Key Vault
Estado externo
| Capa | Servicio | Cachea |
|---|---|---|
| Datos | Azure Cache for Redis | Resultados de queries, sesiones, objetos calientes (cache-aside) |
| Edge global | Front Door (+CDN) | Contenido estático y dinámico acelerado en POPs globales |
| API | API Management (policy de cache) | Respuestas de API por clave/parámetros |
| Estáticos | Blob estático + CDN/Front Door | SPA, imágenes, descargas |
| Herramienta | Cuándo |
|---|---|
| Azure DevOps (Pipelines) | CI/CD empresarial: build → test → release con aprobaciones, gates y entornos. Integra con repos Azure Repos, GitHub o cualquier git |
| GitHub Actions | Flujos nativos en GitHub: workflows YAML en el repo, marketplace de actions, integración con OIDC para credenciales sin secrets |
| Azure Deployment Environments | Provisionar entornos completos (IaC plantillas) bajo demanda para dev/test — autoservicio con gobernanza central |
| Deployment slots (App Service) | Blue/green sin downtime dentro de App Service — swap entre staging y producción con warmup previo |
| Bicep / Terraform (IaC) | Infraestructura declarativa versionada en el repo — prerequisito de despliegues repetibles y revisables |
| GitOps + Flux/ArgoCD (AKS) | El cluster reconcilia su estado contra el repo git — cambios de configuración = PR, no comandos manuales |
Señales del examen
"Desplegar a múltiples entornos con aprobación manual antes de producción" → Azure Pipelines con gates/environments. "El equipo ya usa GitHub" → GitHub Actions. "IaC repetible sin diferencias entre entornos" → Bicep/Terraform en pipeline. "Clusters AKS sin comandos manuales al cluster" → GitOps.
| Requisito | Diseño |
|---|---|
| Deploy sin downtime con rollback inmediato | Deployment slots + swap |
| La app llega a una SQL privada en la VNet | Regional VNet integration (Premium) |
| La app solo accesible desde la red privada | Private Endpoint (+ deshabilitar acceso público) |
| App Service single-tenant 100% en tu VNet | ASE v3 (Isolated v2) |
| Solo aceptar tráfico que venga de Front Door | Access restrictions (service tag + header X-Azure-FDID) |
| Picos de tráfico saturan el procesamiento de pedidos | Cola (Service Bus) + workers que escalan (load leveling) |
| Feature flags y config central multi-app | Azure App Configuration |
| Migración incremental del monolito | Strangler fig con APIM/App Gateway al frente |
| Sesiones de usuario al escalar horizontalmente | Redis como session store (app stateless) |
| CI/CD con aprobación manual antes de producción | Azure DevOps Pipelines (environments + approvals) |
| Flujo de despliegue nativo al repo de GitHub | GitHub Actions |
| Entornos de dev/test bajo demanda con IaC | Azure Deployment Environments |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una web de venta de entradas colapsa cuando salen entradas populares: la API de pedidos recibe 50x el tráfico normal y la base de datos se satura, perdiendo pedidos. El negocio acepta que la confirmación del pedido tarde unos segundos más durante picos. ¿Qué patrón aplicas?
Inicia sesión para llevar tu progreso.