Papel a microservicios

El dolor

Esta empresa tenía cientos de empleados y más de treinta procesos que dependían de papel. Partes diarios que se llenaban a mano y se escaneaban. Inventario que vivía en una planilla. Capacitaciones que se registraban en un cuaderno. Prevención de riesgos documentada en formularios que después nadie encontraba.

El problema más grande no era la ineficiencia — era la falta de trazabilidad. Cuando algo salía mal, no había forma fácil de saber qué había pasado, quién había firmado qué, ni en qué estado estaba un proceso. Cada auditoría era una búsqueda en archivadores.

Lo que cambió

El proyecto se hizo por fases. Cada servicio que se digitalizaba tenía que funcionar sin romper lo que ya existía al lado. Pipelines con quality gates para que nada llegara a producción sin pasar pruebas automáticas. Deploy en Kubernetes con ArgoCD para tener control total sobre qué versión está corriendo y poder hacer rollback si algo falla.

Hoy son más de treinta servicios digitales que reemplazaron formularios físicos, partes diarios, inventario, registros de capacitación y documentación de prevención de riesgos. Lo que antes tomaba semanas — completar un formulario, que lo firmara el jefe, archivarlo, encontrarlo después — tarda minutos.

30+ procesos digitalizados. Deploy continuo con quality gates. Trazabilidad completa en cada operación.

Arquitectura

El desafío más grande no fue técnico — fue de secuenciación. No puedes digitalizar treinta procesos al mismo tiempo sin romper la operación. Definimos una matriz de impacto versus complejidad y atacamos de mayor impacto hacia abajo, para que las victorias fueran visibles desde las primeras semanas y el proyecto mantuviera respaldo interno.

La base de datos legada era SQL Server. No la tocamos. Construimos los nuevos servicios con sus propias bases de datos y cuando necesitaban datos históricos del sistema viejo, los jalábamos vía una capa de integración. Es una solución incómoda, pero honesta: una migración de SQL Server mid-project habría sido un riesgo enorme con cero beneficio visible para los usuarios.

Jenkins como CI no fue una elección entusiasta — fue un requerimiento del cliente. La empresa tiene política de no usar herramientas SaaS de terceros para su pipeline de producción. Todo corre en servidores propios. ArgoCD maneja el deploy en Kubernetes siguiendo GitOps: el estado del cluster se define en git y ArgoCD lo reconcilia. Nadie puede hacer kubectl apply manualmente en producción.

Los quality gates del pipeline validan cobertura mínima de tests, análisis estático con SonarQube, y que ningún secreto esté commiteado en el código. En un proyecto con múltiples equipos tocando el mismo repositorio, esos gates son lo que permite mergear sin miedo todos los días.

Stack

Qué aprendimos

El mayor problema no fue tecnológico — fueron los usuarios. La gente llevaba años llenando el mismo formulario en papel. Cuando aparece una pantalla nueva, el rechazo es instintivo. Pasé más tiempo del que esperaba haciendo sesiones de capacitación y ajustando flujos basados en feedback real de los funcionarios. Sin eso, el sistema habría quedado instalado pero no usado.

Kubernetes es poderoso y también es costoso de operar. Para servicios con tráfico predecible y sin requerimientos especiales de scaling, la complejidad de K8s es overkill. Lo usamos porque el cliente ya tenía el cluster y era política interna. En otro contexto, con otro cliente, habría elegido algo más simple.

La documentación de contratos entre servicios es deuda que se acumula rápido. Cuando hay treinta servicios comunicándose entre sí, sin OpenAPI actualizado el debug se convierte en arqueología. Implementé bien los últimos quince servicios. Los primeros quince los pagué con tiempo de depuración.

Servicios relacionados