Ecosistema de nueve aplicaciones con identidad federada
No es un proyecto: es el sistema de sistemas sobre el que vivieron todos los demás. Nueve aplicaciones en producción en Azure, una sola identidad corporativa, y un solo desarrollador durante tres años.
El código es propiedad de la empresa y está sujeto a acuerdo de confidencialidad. Lo que se cuenta aquí es la clase de sistema y la clase de problema, nunca la arquitectura concreta, el modelo de datos, los nombres internos ni cifras de uso.
Nueve aplicaciones, una sola identidad corporativa, un solo desarrollador y ninguna tolerancia a que cada sistema tenga su propio login y su propio usuario duplicado. El coste de mantenimiento de nueve sistemas distintos entre sí es superior al que una persona puede sostener.
Una fuente de verdad de identidad y una base técnica común, repetida deliberadamente en vez de optimizada localmente. Sin eso no son nueve aplicaciones: son nueve problemas.
Un hub que actúa de proveedor de identidad y de fuente única de usuarios y grupos; las aplicaciones hijas no gestionan identidad propia y se sincronizan por API. Debajo, una base técnica repetida a propósito entre todas.
- Login corporativo con Entra ID y SSO por JWT propio entre aplicaciones: nadie mantiene un usuario duplicado.
- La base técnica repetida a propósito —configuración modular, grupos por rol, registro global de actividad, aplicaciones de solo modelos— es lo que permite a una sola persona sostener nueve sistemas.
- Internacionalización en cuatro idiomas con herramienta propia de traducción de catálogos.
Lo que demuestra9
- Construir identidad federada y SSO entre aplicacionesDecisión escrita · Solo en conversación
Login corporativo con Entra ID en el hub, SSO por JWT propio hacia las aplicaciones hijas, y sincronización de usuarios y grupos por API. Ninguna hija gestiona identidad.
- Operar aplicaciones en la nubeDecisión escrita · Solo en conversación
- Montar integración y despliegue continuosHistorial de commits · Métrica
- Llevar una necesidad hasta producción sin tutelaMétrica · Documento propio
- Diseñar una capa de servicios de dominio agnóstica de interfazDecisión escrita · Solo en conversación
- Internacionalizar de verdad y verificarloDecisión escrita · Solo en conversación
- Integrar servicios de terceros por APIDecisión escrita · Solo en conversación
- Entrar en código ajeno o antiguo y evolucionarloDecisión escrita · Solo en conversación
- Defender criterio técnico ante direcciónDecisión escrita · Solo en conversación
Principios que se ven aquí4
- PrincipioLa autocrítica se publica, no se guarda
- «Hard work and execution, but based on erroneous initial premises» — autocrítica en una presentación interna sobre su propio trabajo
- PrincipioUna acción existe una vez; todas las interfaces la llaman
- Base técnica repetida a propósito entre nueve aplicaciones: es lo que permite a una sola persona sostenerlas
- PrincipioUn sistema entregado no es un sistema adoptado, y lo he medido en mi contra
- Herramientas retiradas por no tener uso real, en vez de mantenidas por no reconocerlo
- PrincipioEn producción, lo mínimo que resuelve el problema
- Sin Docker, Redis ni Celery por defecto: criterio escrito y sostenido en nueve aplicaciones en producción