Agustín Domínguez

Enero 2024 - Actualidad

Desarrollo y automatización de sistemas internos para un ISP de infraestructura y servicios FTTH.

Problema

La operación de un ISP FTTH depende de múltiples plataformas (facturación, CRM, infraestructura de red, monitoreo) que originalmente no fueron diseñadas para compartir información entre sí.

Solución

APIs REST y servicios backend que integran plataformas operativas y de infraestructura, además de herramientas internas para automatizar procesos que antes eran manuales.

Arquitectura

Servicios en Python/FastAPI dockerizados, desplegados sobre Linux, con documentación de API mediante OpenAPI/Swagger y automatizaciones orquestadas con n8n.

Mi rol

Software Developer / Backend Software Engineer: desarrollo de APIs, integraciones, automatización de procesos y mantenimiento de sistemas existentes.

Desafíos

Sincronizar información entre plataformas con modelos de datos distintos (SmartOLT, GeoGrid, Anatod, Odoo) y con limitaciones de webhooks en algunos sistemas.

Decisiones

Priorizar integraciones basadas en APIs y logs/históricos por sobre soluciones frágiles de scraping, y mantener la lógica de negocio en servicios versionados en vez de concentrarla en workflows.

Resultado

En operación continua como parte de la infraestructura de software de la empresa.

Wiber — Investigación en curso

Investigación e ingeniería inversa funcional de las APIs de GeoGrid y Anatod para habilitar integraciones sobre infraestructura FTTH.

Problema

GeoGrid (gestión de infraestructura de fibra) y Anatod (operación/comercial) necesitan mantenerse sincronizados, pero no existía un mapeo claro de sus modelos de datos ni de cómo se relacionaban las entidades entre ambos sistemas.

Solución

Investigación sistemática y de solo lectura sobre los dominios de ambas APIs (autenticación, ítems de red, equipamientos, puertos, viabilidad, clientes, cables, históricos), documentando relaciones como ItemRede → Equipamento → Porta y Cliente → Atendimento → Porta/Equipamento.

Arquitectura

Para explorar y validar hallazgos se construyó una herramienta propia en FastAPI con ~14 endpoints proxy sobre los dominios investigados, con Swagger, logging y reintentos de transporte, convirtiendo una investigación manual en un proceso reproducible.

Mi rol

Investigación técnica, diseño del explorador de API y análisis del modelo de datos para una futura sincronización mediante microservicios.

Desafíos

Ausencia de documentación oficial completa y limitaciones de webhooks, lo que llevó a evaluar estrategias alternativas basadas en históricos, logs e identificación de cambios.

Decisiones

Descartar integraciones ad-hoc y en su lugar modelar la sincronización como un problema de microservicios especializados, apoyado en la herramienta de exploración como base de conocimiento reutilizable.

Resultado

Modelo de dominio documentado y herramienta de exploración reutilizable; base para el proyecto de reserva de puertos FTTH y para futuras sincronizaciones automatizadas.

Wiber — En diseño/implementación

Evolución de la infraestructura de automatización interna hacia una arquitectura de microservicios documentada mediante ADRs.

Problema

Los procesos de automatización estaban concentrados en una herramienta existente (Wizer/n8n), generando acoplamiento y workflows cada vez más complejos y difíciles de mantener o testear.

Solución

Arquitectura basada en microservicios especializados que encapsulan lógica de negocio versionada y testeable, con n8n como orquestador liviano en vez de contenedor de toda la lógica.

Arquitectura

Docker Compose como plataforma de orquestación, Traefik como reverse proxy, PostgreSQL para persistencia relacional y Redis cuando el caso de uso lo requiere.

Mi rol

Diseño de las decisiones de arquitectura y documentación técnica del proceso mediante un enfoque propio de Decision-Centric Engineering (ADRs versionados en Git: plataforma de orquestación, reverse proxy, topología, persistencia, mensajería).

Desafíos

Elegir el nivel de complejidad adecuado para el contexto real: un único host, pocos servicios, un administrador principal y servicios internos no customer-facing.

Decisiones

Se descartó introducir Kubernetes prematuramente por no estar justificado por la escala actual, priorizando simplicidad operacional sobre arquitectura especulativa.

Resultado

En evolución progresiva; decisiones documentadas y trazables mediante ADRs para sostener la arquitectura a medida que crece.