Arquitectura Azure para la demo académica

Estado y propósito

Este documento fija la arquitectura objetivo de M10 para una demostración académica pública de hasta tres meses. Es un diseño reproducible y acotado; no es una autorización para producción ni un SLA. La infraestructura debe permanecer apagada o en escala cero cuando no se use y no debe contener datos reales o personales.

La suscripción aplica una política de regiones que permite westus; por ello el backend y PostgreSQL se despliegan allí. Frontend y manuales salen del Resource Group y se sirven desde Cloudflare Pages Free, que no está sujeto a la política de regiones Azure.

Diagrama lógico

flowchart LR
    reviewer[Revisor académico] --> pages[Cloudflare Pages Free\nfrontend + MkDocs]
    pages -->|HTTPS + CORS limitado| aca[Azure Container Apps Consumption\nFastAPI]
    aca -->|CONNECTION_PROFILE=fixture| fixtures[Fixtures sintéticos versionados]
    aca -. opcional .-> pg[PostgreSQL Flexible Server\nhistorial/auditoría]
    aca --> health[/health y /api/v1/readiness]
    aca --> logs[Logs y métricas de Container Apps]
    budget -.-> aca
    budget -.-> pg

El frontend nunca accede directamente a PostgreSQL, fixtures, secretos ni motores NoSQL. El backend conserva la autoridad de análisis y, por defecto, usa CONNECTION_PROFILE=fixture; MongoDB, CouchDB y Cassandra no se exponen públicamente.

Cloudflare Pages Free es el proveedor seleccionado para frontend y manuales. Azure Static Web Apps fue evaluado, pero no se habilitó en M10; el parámetro staticWebAppsEnabled=false del despliegue expresa esa decisión. No se debe confundir una alternativa evaluada con un recurso creado.

Recursos y límites

Recurso SKU/política Límite de demo Persistencia/ciclo de vida
Resource Group tags project, environment, owner, expires_on, cost_center Un grupo dedicado, sin recursos ajenos Se elimina al finalizar M10, previa exportación de evidencia
Cloudflare Pages Free Dos proyectos: frontend y manuales; límites del plan Free Frontend y documentación reemplazables por despliegue
Container Apps Environment Consumption Un entorno dedicado Compartido por la revisión; se elimina con la demo
Container App backend Consumption, minReplicas=0, maxReplicas=1 inicialmente CPU/memoria mínimos y regla HTTP Revisión sustituible; rollback a revisión saludable
PostgreSQL Flexible Server Opcional, SKU mínimo compatible con la cuota Solo si se necesita conservar historial/auditoría Recurso separado del ciclo del contenedor; respaldo antes de eliminar
Key Vault/managed identity No requerido para el primer diseño Solo se incorpora si el entorno lo exige Queda para hardening posterior M12

La arquitectura no promete gratuidad absoluta: el consumo, almacenamiento, IPs, registros o servicios fuera de la cuota pueden generar crédito consumido. Por eso el presupuesto debe tener alertas, límites, etiquetas y un procedimiento de pausa/eliminación.

Supuestos y decisiones

  1. La suscripción es Azure for Students y la cuenta autorizada puede crear únicamente el Resource Group dedicado de M10.
  2. La aplicación se publica para revisión académica, no para producción; no se declara SLA, alta disponibilidad, SSO, multi-tenancy ni soporte 24/7.
  3. CONNECTION_PROFILE=fixture es el valor público inicial. Los datos son sintéticos y se regeneran desde el repositorio.
  4. PostgreSQL es opcional. Si no se aprueba su costo, la demo conserva SQLite/local solo para validación y declara que el historial público no es persistente.
  5. La escala mínima del backend es cero. El primer request puede tardar por arranque en frío; el frontend debe comunicarlo y esperar readiness.
  6. No se despliegan MongoDB, CouchDB ni Cassandra públicos. Los adaptadores live siguen siendo opt-in y se validan localmente/CI.
  7. El despliegue se hará únicamente desde main y con credenciales de GitHub/Azure/Cloudflare fuera del repositorio. Nunca se guardan tokens, URI, contraseñas o claves en Bicep, logs, artifacts o frontend. El token corto de smoke permanece exclusivamente en GitHub Actions; el frontend público no recibe VITE_AUTH_TOKEN.

Matriz de costo y guardas

Elemento Tratamiento gratuito o acotado Riesgo de consumo Guarda obligatoria
Cloudflare Pages Free Dos sitios estáticos, sin Workers adicionales para M10 Límites de builds, archivos y funciones del plan Free No activar Workers/R2 pagos sin decisión
Container Apps Consumption minReplicas=0, maxReplicas=1, CPU/memoria mínima Requests, CPU y memoria mientras se revisa Pausar fuera de horario; budget y alerta
PostgreSQL Flexible Server Burstable Standard_B1ms, 32 GB, backup 7 días, HA/georedundancia desactivadas Costo de servidor y almacenamiento aun con poco tráfico Solo se crea tras confirmar cuota Free; recurso separado, retención definida, pausa/eliminación explícita
Log Analytics Retención mínima compatible de 30 días para PerGB2018; volumen mínimo Ingesta de logs Filtrar datos sensibles y no superar la retención mínima del SKU
Registro de imágenes GitHub Container Registry o equivalente de baja cuota Almacenamiento de tags Retener solo revisiones necesarias y limpiar tags
Azure DNS/dominio No requerido; usar URL administrada Dominio y renovación No contratar dominio para la demo

Antes de aplicar Bicep se deben crear/confirmar: disponibilidad Free en la suscripción, budget si el rol lo permite, tags con fecha de expiración, límites de Container Apps y una persona responsable de apagar. Azure for Students mantiene activo el spending limit; los budgets son alertas y no detienen consumo. El procedimiento de pausa y eliminación de M10 se documentará en OPS-04 (#90).

Variables y secretos

Las variables no sensibles se parametrizan en Bicep o en el entorno de despliegue: APP_ENV, CONNECTION_PROFILE, FRONTEND_ORIGIN, DATABASE_URL_REF, AUTH_SIGNING_KEY_REF, REPORT_RETENTION_DAYS y AUDIT_RETENTION_DAYS. Los valores sensibles solo se entregan como referencias de secretos de Container Apps/GitHub Environment. El frontend recibe únicamente una URL pública y, si se habilita, un token corto para demo; nunca recibe credenciales de base de datos.

Validación y límites conocidos

  • Bicep debe compilarse/lintarse en CI sin autenticarse contra Azure.
  • Un despliegue real requiere una suscripción, permisos de creación, una región disponible y una política de costos aprobada.
  • La publicación pública y el smoke externo se mantienen bloqueados mientras no exista una URL pública y credenciales de despliegue configuradas en GitHub Environment.
  • La revisión de M10 no convierte esta arquitectura en producción: M12 cubre hardening, disponibilidad, SLO/RPO/RTO, identidad empresarial y continuidad.

Referencias

Diagramas generados desde fuentes versionadas: