Goliat Nexus: una base modular para desplegar aplicaciones en Azure

Daniel J. Saldaña
1 de noviembre de 2026
- DevOps
Puntuación de feedback

Al empezar una aplicación en Azure aparecen muchas decisiones antes de escribir la primera funcionalidad: cómo separar los entornos, dónde guardar los secretos, cómo publicar las APIs, qué servicios compartir y cómo repetir el despliegue sin depender de pasos manuales.

Con esa idea he creado Goliat Nexus, una base modular que reúne infraestructura con Terraform, configuración por entorno y una aplicación de ejemplo para recorrer la arquitectura de principio a fin.

Web oficial y diagramas: Abrir la web de Goliat Nexus

Código en GitHub: Ver el repositorio de Goliat Nexus

La propuesta es que puedas entender las piezas, desplegarlas y adaptarlas a tu proyecto. El repositorio reúne el código de infraestructura y el de las aplicaciones.

Un hub compartido y dos entornos separados

La decisión central de Nexus es compartir los servicios comunes entre Dev y Prod. Así se evita crear otra copia del registro de contenedores, la entrada pública o la plataforma de logs para cada entorno.

Cada entorno conserva sus propias aplicaciones, identidades y datos:

Ámbito	Qué contiene
Hub compartido	Application Gateway con WAF, Azure Firewall, Azure Container Registry, DNS privado, Log Analytics y backend de estado Terraform.
Dev	Su red spoke, Container Apps, portales de ejemplo, APIs, Azure Functions, Cosmos DB, Storage, Key Vault e identidades.
Prod	Su propia red spoke y sus propios componentes de aplicación y datos, con capacidad configurable por separado.

Dev y Prod no tienen un peering directo entre sí. Comparten servicios de plataforma a través del hub, mientras mantienen sus recursos de aplicación separados.

Esta organización permite ajustar réplicas y capacidad según el entorno. También hace visible qué recursos pertenecen a la plataforma y cuáles a una aplicación concreta.

Entrada pública protegida, APIs y datos privados

El recorrido de una petición empieza en una entrada HTTPS protegida por Application Gateway WAF:

Usuario + Microsoft Entra ID
              ↓
Application Gateway WAF compartido
              ↓
Web del entorno / acceso a las APIs
              ↓
Gateway y APIs privados
              ↓
Cosmos DB, Storage y Key Vault

Los orígenes de las webs restringen el acceso a la IP del WAF y el gateway privado limita su entrada a la subred correspondiente. Las APIs validan identidad, permisos y acceso a los registros en cada petición.

Conviene distinguir la entrada pública del tráfico interno. Los eventos entre una API, una cola y una Function no recorren el WAF público. Su protección se apoya en conectividad privada, identidades y permisos específicos. Azure Firewall cumple una función distinta, relacionada con la salida autorizada de red.

Ese es el enfoque Zero Trust de la base: acceder a la red no concede por sí mismo acceso a los datos. La configuración de identidad y las políticas de la organización siguen formando parte del diseño de cada proyecto.

Alba: una aplicación para probar el conjunto

Nexus incluye Alba, un ejemplo de aplicación de solicitudes que conecta frontend, backend, persistencia y procesamiento asíncrono.

Pieza	Papel en el ejemplo
Dos portales Next.js estáticos	Una vista de usuario y otra de operaciones, con inicio de sesión mediante Microsoft Entra ID.
APIs Node.js en Container Apps	Catálogo, solicitudes y actividades, con validación de tokens y autorización.
Cosmos DB compatible con MongoDB	Persistencia de solicitudes y actividades de cada entorno.
Storage Queue	Transporte de eventos para procesarlos de forma asíncrona.
Azure Functions	Consumo de la cola y recuperación de publicaciones pendientes.
Key Vault	Custodia de los secretos que necesitan las aplicaciones.

Los portales son interfaces de ejemplo. Puedes sustituirlos por tu frontend y adaptar las APIs y los eventos a tu dominio. La vista de administración tampoco concede permisos por sí sola: los roles se asignan en Entra y los comprueba el backend.

Qué ocurre al enviar una solicitud

El flujo permite observar comportamientos que aparecen en aplicaciones reales:

El usuario inicia sesión y envía una solicitud con su token y un identificador único.
La API valida el contenido, los permisos y el propietario, y guarda la solicitud junto con la información necesaria para publicar su evento.
El evento se envía a la cola y una Function lo procesa para registrar la actividad.
El portal consulta a la API para mostrar el resultado y la actividad disponible.
Si una publicación queda pendiente, un proceso de recuperación vuelve a intentarla.

La cola puede entregar un evento más de una vez. Por eso el consumidor controla los duplicados. Una respuesta de aceptación de la API confirma que existe la solicitud, pero el procesamiento asíncrono puede seguir pendiente.

Este ejemplo ayuda a entender la relación entre reintentos, persistencia y consistencia eventual antes de añadir la lógica de negocio de tu producto.

Configuración comentada y módulos que se pueden adaptar

La instalación se organiza en tres archivos principales:

environments/common.tfvars: región, identidad, red compartida, estado y operación común.
environments/dev.tfvars: componentes, acceso y capacidad de Dev.
environments/prod.tfvars: componentes, acceso y capacidad de Prod.

Las plantillas HCL incluyen comentarios y utilizan valores ficticios. La configuración real se genera en archivos locales protegidos. El CLI deriva después las entradas .auto.tfvars.json que consume Terraform.

Los portales se definen mediante un mapa:

# Cada entrada crea una publicación Static Web Apps.
# view selecciona una de las interfaces de ejemplo disponibles.
web_portals = {
  tenant = { view = "tenant" }
  admin  = { view = "admin" }
}

Añadir una entrada permite crear otra publicación reutilizando las vistas disponibles. Para una interfaz distinta debes aportar su código. Esta separación permite ampliar el despliegue sin añadir un flag nuevo por cada portal.

La base también contempla componentes opcionales, como almacenamiento de contenido, Event Grid o una máquina privada para un agente de GitHub Actions. Cada capacidad requiere su configuración; por ejemplo, habilitar Event Grid no crea automáticamente un flujo de negocio ni sustituye el consumidor de Queue de Alba.

Despliegue, costes y operación

El despliegue se coordina en cinco capas: foundation → platform → Dev → Prod → edge. Cada una conserva su estado y un plan guardado, y utiliza los outputs de las capas anteriores.

La publicación y la administración necesitan un ejecutor con conectividad y DNS privados. La documentación explica el arranque por fases y el agente opcional para ese trabajo.

Compartir infraestructura evita duplicar servicios comunes, pero el coste final depende de los componentes y de la capacidad elegida. WAF, Firewall y ACR tienen coste incluso con poca actividad. Los presupuestos sirven para avisar; no detienen automáticamente el gasto.

Antes de usar la base en producción, hay que validar permisos, dominios, carga, recuperación y políticas de identidad en el entorno concreto. Nexus incluye pruebas automatizadas y guías de aceptación para acompañar esa revisión.

Por dónde empezar

La web de Goliat Nexus permite explorar los diagramas y seguir un recorrido de la aplicación con datos ficticios. Ese recorrido es una simulación; desplegar la instalación de evaluación sí crea recursos en Azure.

Enlaces oficiales de Goliat Nexus

La otra herramienta de esta familia, Goliat Cloud Inventory, aborda el inventario y la consulta de costes. Ambas pueden utilizarse de forma independiente: Nexus prepara una base para tus aplicaciones e Inventory ayuda a explorar los recursos de Azure.