Esta ruta conecta los conceptos necesarios para publicar y operar aplicaciones HTTP sobre Azure App Service. No es un tour de botones del portal: el objetivo es que entiendas el modelo mental —qué es cada pieza, cómo se relaciona con las demás y qué decisiones tomas en producción— para que cuando llegues a la consola sepas exactamente qué estás configurando y por qué.
App Service es el PaaS de Azure para alojar aplicaciones web, APIs y backends móviles sin gestionar servidores. Tú subes código o un contenedor; la plataforma se encarga del sistema operativo, el runtime, el parcheo, el balanceo y el escalado. A cambio de esa comodidad cedes algo de control, y buena parte de esta ruta trata precisamente de dónde está esa frontera.
Empieza por Azure y continúa en el orden mostrado en la navegación. Cada página asume lo aprendido en la anterior.
Antes de tocar nada conviene fijar el vocabulario. Estos tres términos se usan como sinónimos en conversaciones informales, pero son cosas distintas:
| Concepto | Qué es | Analogía |
|---|---|---|
| App Service Plan | El conjunto de recursos de cómputo (VMs gestionadas) y su tier de precio. | El edificio y su contrato de alquiler. |
| App Service | El servicio de Azure que ejecuta tus apps sobre ese plan. | El sistema del edificio que da luz, agua y seguridad. |
| Web App | Tu aplicación concreta (código o contenedor) corriendo dentro del plan. | El inquilino que vive en un piso. |
La regla clave: varias Web Apps pueden compartir un mismo App Service Plan. Comparten CPU, memoria y coste. Esto es potente para consolidar entornos pequeños, pero peligroso si una app ruidosa agota los recursos de las demás.
Un error frecuente es crear un plan por cada app “por si acaso”. Terminas pagando capacidad ociosa multiplicada. El error opuesto —meter todo en un solo plan barato— provoca contención cuando una app tiene un pico. La decisión correcta depende del perfil de carga, y la tomarás mejor cuando entiendas los tiers.
App Service es una buena opción cuando:
Conviene mirar otras opciones si:
Una topología típica de una Web App en producción combina varias piezas de la plataforma alrededor del App Service:
Internet
│
▼
[ Azure Front Door / Application Gateway ] ← WAF, TLS, enrutado
│
▼
[ App Service Plan ]
├── Web App (slot: production)
└── Web App (slot: staging) ← swap sin downtime
│
├── Managed Identity ──▶ [ Key Vault ] (secretos)
├── VNet Integration ──▶ [ Azure SQL / Redis ] (datos privados)
└── Diagnostics ──▶ [ Application Insights ] (observabilidad)La idea es que el tráfico entra por una capa de borde (TLS, WAF, caché), la app obtiene sus secretos e identidad de servicios gestionados en lugar de llevarlos en el código, y toda la telemetría fluye a un único sitio donde puedas correlacionar errores, latencia y despliegues.
La configuración de una Web App vive en App Settings y Connection Strings, que Azure inyecta como variables de entorno en tiempo de ejecución. La regla de oro: el código no debe contener secretos. En su lugar:
Un ejemplo de referencia a Key Vault en un App Setting:
# El valor del App Setting no es el secreto, sino un puntero a Key Vault.
@Microsoft.KeyVault(SecretUri=https://mi-vault.vault.azure.net/secrets/DbPassword/)Y una lectura desde la aplicación (Node.js) que nunca ve el secreto en texto plano en el repositorio:
// La plataforma ya resolvió la referencia de Key Vault en la variable de entorno.
const connectionString = process.env.DATABASE_CONNECTION_STRING
if (!connectionString) {
throw new Error("Falta DATABASE_CONNECTION_STRING en la configuración")
}[!NOTE] Las Managed Identities eliminan la necesidad de rotar credenciales manualmente: la identidad la gestiona Azure AD y la app se autentica sin contraseñas.
Por defecto una Web App es pública. Para producción normalmente querrás acotar la superficie:
La combinación habitual es entrada por Front Door + salida por VNet Integration, dejando la app sin exposición directa a Internet.
Los slots son copias en vivo de tu app (por ejemplo staging y
production) que comparten el mismo plan. El flujo seguro es:
staging.staging con su propia URL.staging y production.El swap es casi instantáneo y precalienta la app antes de recibir tráfico, lo que evita el “cold start” del primer usuario. Si algo sale mal, un swap inverso te devuelve a la versión anterior en segundos.
Algunos App Settings deben viajar con el slot (por ejemplo, apuntar a una base de datos de staging) y otros deben quedarse fijos al entorno tras el swap. Azure lo resuelve con la opción “deployment slot setting” (sticky settings): esos valores no se intercambian durante el swap.
App Service ofrece dos ejes de escalado:
| Estrategia | Cuándo | Riesgo |
|---|---|---|
| Scale up | La app necesita más recurso por instancia (memoria, CPU sostenida). | Punto único; sigues con una sola instancia si no escalas out. |
| Scale out | Tráfico concurrente alto o picos. | La app debe ser stateless; el estado va a Redis/DB. |
| Autoscale | Carga variable y predecible por métricas. | Reglas mal calibradas causan flapping o coste. |
[!TIP] Diseña la app stateless desde el principio. Guardar sesión en memoria local rompe en cuanto escalas a más de una instancia.
No puedes operar lo que no puedes ver. El estándar en App Service es Application Insights, que te da:
Complementa con Health Checks: un endpoint (/health) que App Service
sondea para retirar de rotación las instancias enfermas automáticamente.
// Endpoint de salud mínimo: comprueba dependencias críticas antes de responder OK.
app.get("/health", async (_req, res) => {
try {
await db.ping()
res.status(200).json({ status: "ok" })
} catch {
res.status(503).json({ status: "degraded" })
}
})El coste de App Service lo domina el tier del plan, no el número de apps (recuerda: varias apps comparten plan). Factores a vigilar:
Errores de coste habituales:
Cada página de la ruta profundiza en uno de estos bloques y se conecta con los demás en el grafo de conocimiento. Una lectura recomendada:
Cuando termines deberías poder mirar una Web App desconocida y, en pocos minutos, entender cómo está desplegada, dónde guarda sus secretos, cómo escala y qué pasa cuando falla.