16 · Azure y endpoints gestionados
AWS no es la única nube. Azure ofrece el mismo espectro de gestionado-vs-control: Container Instances (un contenedor, rápido), Container Apps (serverless, escala a cero, autoescalado) y endpoints de ML gestionados. El patrón es portable — empareja el servicio con el requisito, no la nube.
El patrón de despliegue es el mismo en cada nube — elige un servicio según cuán gestionado y cuán escalable lo necesites — solo cambian los nombres. En Azure: **Container Instances (ACI)** corre un solo contenedor rápido (`az container create`) sin orquestación — genial para un trabajo rápido o un servicio simple siempre-encendido. **Container Apps** son contenedores serverless con autoescalado y **escala a cero** (no pagas nada cuando está inactivo) — el predeterminado moderno para un servicio web/de modelo con tráfico variable. Los **endpoints de ML gestionados** (Azure ML, espejo de AWS SageMaker y GCP Vertex AI) dan un endpoint de serving de modelos totalmente gestionado, con autoescalado y monitoreado. La habilidad es portable: empareja el requisito con el peldaño correcto del espectro, sin importar qué logo de nube tenga encima.
Sin esto:
Sin ver el patrón entre nubes, tratarías a cada proveedor como un sistema nuevo que reaprender — y recurrirías a cualquier servicio que conozcas en lugar del que de verdad encaja con el requisito (p. ej. una instancia siempre-encendida para un servicio a ráfagas y casi inactivo que escala-a-cero habría corrido por una fracción del costo).
AWS (lección 15) no es todo el mundo — Azure y GCP alojan tanto ML en producción como cualquiera. La buena noticia: la decisión de despliegue es la misma en todas partes. Cada nube grande ofrece el mismo espectro de gestionado-vs-control que aprendiste para AWS; solo difieren los nombres de los productos. Aprende la forma una vez y puedes desplegar en cualquiera de ellas.
En Azure, los peldaños contenerizados son:
-
Azure Container Instances (ACI) — el más simple: corre un único contenedor, rápido, sin capa de orquestación. Un comando,
az container create, apunta a tu imagen (en Azure Container Registry, el equivalente de ECR en Azure) y obtienes un contenedor corriendo con una IP/FQDN pública. Es el análogo de "solo corre este contenedor" — perfecto para un trabajo por lotes rápido o un servicio simple siempre-encendido, pero no hay autoescalado ni escala-a-cero incorporados. -
Azure Container Apps — contenedores serverless con orquestación real: autoescalado según el tráfico y, crucialmente, escala a cero — cuando no llegan solicitudes, baja a cero réplicas y no pagas nada, luego vuelve a levantarse en la siguiente solicitud. Este es el predeterminado moderno para una API de modelo con tráfico variable o a ráfagas: obtienes autoescalado y balanceo de carga sin gestionar servidores, y no pagas por capacidad inactiva. Es aproximadamente la respuesta de Azure a AWS Fargate / Google Cloud Run.
-
Endpoints gestionados de Azure ML — como los endpoints de AWS SageMaker: despliega un modelo y obtén un endpoint de serving HTTPS totalmente gestionado, con autoescalado y monitoreado, nativo de ML (versionado incorporado, rollout azul-verde, captura de datos para monitoreo). La elección cuando lo que quieres es serving de modelos gestionado.
Los mismos tres niveles existen en cada nube. Vale la pena verlos lado a lado:
| Necesidad | AWS | Azure | GCP | |---|---|---|---| | Correr un contenedor, rápido | (ECS task) | Container Instances | Cloud Run job | | Contenedor serverless con autoescalado, escala a cero | Fargate / App Runner | Container Apps | Cloud Run | | PaaS gestionado para un contenedor | Elastic Beanstalk | App Service | App Engine | | Endpoint de serving de ML totalmente gestionado | SageMaker | Endpoint de Azure ML | Endpoint de Vertex AI | | VM cruda (control total) | EC2 | Azure VM | Compute Engine | | Registry de contenedores | ECR | Azure Container Registry | Artifact Registry |
La lección es la habilidad portable: empareja el requisito con el peldaño, no con la nube. Una API de modelo a ráfagas y casi inactiva → un contenedor serverless con escala-a-cero (Container Apps / Cloud Run / Fargate). Un servicio estable de alto tráfico que necesita monitoreo nativo de ML y A/B → un endpoint de ML gestionado (Azure ML / SageMaker / Vertex). Un contenedor de una sola vez → el servicio de correr-un-contenedor. Elige la nube por las razones que de verdad difieren entre ellas — cuentas existentes, precios, el resto de tu stack — pero la forma del despliegue ya la conoces.
Comandos de despliegue de Azure: `az container create` corre un solo contenedor en Container Instances (sin autoescalado), mientras que `az containerapp create` con `--min-replicas 0` da una Container App serverless, con autoescalado y escala a cero — no pagas nada cuando está inactiva.
Tu API de modelo recibe tráfico a ráfagas e impredecible y está inactiva la mayor parte de la noche. Quieres autoescalado y no pagar nada cuando no llegan solicitudes. En Azure, ¿qué servicio encaja?
- La decisión de despliegue es la misma en cada nube — elige según cuán gestionado y cuán escalable lo necesites — solo cambian los nombres de los productos, así que la habilidad es portable.
- En Azure: Container Instances (`az container create`) corre un contenedor rápido sin autoescalado; Container Apps añade autoescalado serverless y escala a cero; los endpoints de Azure ML dan serving de ML gestionado.
- Los niveles se mapean entre proveedores: serverless con escala a cero = Container Apps / Fargate / Cloud Run; endpoint de ML gestionado = Azure ML / SageMaker / Vertex AI — empareja el requisito con el peldaño, no con la nube.
Los equipos despliegan el mismo modelo contenerizado en la nube que ya usan — un contenedor serverless con escala a cero para tráfico a ráfagas, un endpoint de ML gestionado para serving estable de alto tráfico — aplicando la única decisión portable de gestionado-vs-control sin importar el proveedor.
Si lo quitas: Reaprenderías cada nube como un sistema nuevo y recurrirías a cualquier servicio que conozcas en lugar del peldaño correcto — corriendo una instancia siempre-encendida para un servicio casi inactivo que escala-a-cero habría corrido por una fracción del costo.