Core: de AWS a on-prem
El mismo patrón Medallion del framework cloud se portó a on-prem (Windmill + DuckLake). Un patrón agnóstico, dos paradigmas.
03 · Método
Método
Construyo rieles de software: frameworks que optimizan mi trabajo y el del equipo. Una fuente nueva es configuración, no código nuevo. No trabajo con deuda técnica abierta.
La cadena de apalancamiento de 3 niveles
Construyo la plataforma
El framework Core: el motor Medallion estable con su contrato de extensión. La base sobre la que todo lo demás se apoya.
Construyo la CLI que la opera
tf-admin: una sola interfaz para administrar toda la infraestructura, con barandillas en las acciones destructivas.
Construyo los agentes que la manejan
Agentes de IA que operan la CLI de forma segura. El equipo entregó el BI de una aerolínea entera con esta cadena.
Activos reutilizables cross-sector
cortex-ai: de producto a este portfolio
El motor de IA que decide en un producto real es el mismo que responde en el chat de esta página. Un cerebro, dos usos.
El mismo patrón en tres dominios
El mismo verbo —declarar la intención, detectar la deriva, reconciliar— aplicado en tres dominios:
| Dominio | Herramienta | El mismo verbo, aplicado |
|---|---|---|
| Infraestructura | tf-admin | plan / apply sobre Terraform — el caso obvio |
| Operación de BI | bi-ai-tool | Un cliente REST propio que opera Superset y Grafana programáticamente, no clickeando la UI |
| Gestión de proyecto | azure-devops (Tools) | import / diff / apply --dry-run sobre sprints, work items y wiki de Azure DevOps — spec local como fuente de verdad, Azure como runtime |
Automatizar infraestructura es esperable. Aplicar el mismo modelo a cómo se gestiona un proyecto, no.
Optimizo al límite, y dejo escrito dónde está el límite
Uno de mis principios: bajar costos optimizando los recursos hasta el límite antes de escalar. Eso no significa que no toque escalar, o que no se pueda — significa que la decisión de escalar se toma con datos, no por hábito. Seis decisiones: cinco donde la disciplina fue no gastar de más, y una donde fue lo contrario — escalar, porque los números lo pedían.
| Contexto | La decisión | El techo, dicho en voz alta |
|---|---|---|
| BI aviación | Data Mart PostgreSQL, no Redshift | El techo de escala queda explícito y aceptado en el propio caso de estudio |
| BI aviación | Orquestación en Lambdas, no en Glue | Dimensionado contra el volumen real, no especulativo |
| Data Lake distribución | Sobre servidores que la empresa ya tenía | Elegido por tiempo de implementación, con la estructura preparada para migrar cuando haga falta |
| Plataforma de agentes propia | Toda la plataforma en un solo host, deliberadamente pequeño | Documentado como punto único de fallo, con plan de remediación — no escondido |
| Esa misma plataforma, en AWS | Regla escrita: Lambda por defecto, porque no se paga tiempo inactivo | Con su excepción también escrita: cuándo Fargate sí se justifica |
| SQL Server / Siesa | Migrar a disco NVMe — escalar, no recortar | Medido antes de decidir: 25x en operaciones secuenciales, pero solo 1,4x en la latencia que le duele a facturación — no vendí la mejora completa |
La regla: nunca «barato» sin decir hasta dónde, y nunca «hay que escalar» sin decir cuánto se midió antes.
Lidero construyendo y enseñando
Capacito al equipo en IA aplicada y en fundamentos de modelado de datos; está en mis informes de seguimiento del proyecto. En junio, dos personas del equipo hicieron su primer despliegue a producción de forma autónoma. Una de ellas forma hoy a la siguiente persona con el mismo modelo.