Saltar al contenido

Plataforma de ingeniería

Plataforma Soga

Liderazgo de I+D de una plataforma interna de larga vida: servicios Laravel hexagonales, workers en Python y un architecture pack que el trabajo nuevo tiene que seguir.

Jefe de Investigación y Desarrollo de Software · Soga SAS · Junio 2019 — Actualidad

LaravelPHPPythonRedis StreamsMySQLDockerKubernetesNginxHelm
Corte de backend
Dominio Laravel · pipelines Python
Integración
Eventos y gateway — no Eloquent compartido
Entrega
Docker · Kubernetes · Helm

Panorama

Soga es donde se decide la plataforma de ingeniería: cómo se parten los servicios Laravel, cómo corren los workers Python, cómo se ve un payload de stream y qué no puede cruzar un límite.

El rol combina coordinación de equipo, presupuesto, arquitectura e investigación. ProCrédito v2 es el producto más visible sobre esa plataforma; la plataforma es el conjunto de reglas que evitan que el siguiente producto sea un segundo monolito.

Los estándares viven en un architecture pack — capas y slices, layout de servicio Laravel, plantilla de worker Python, convenciones de Redis Streams, contratos, Docker y Kubernetes — no como folklore en los README de cada servicio.

Problema

Una plataforma privada absorbe cada excepción de proceso a menos que alguien posea el modelo. Entregar features sin una función de arquitectura produce bases compartidas, HTTP en workers y magic strings para nombres de campo.

La investigación que no cambia una decisión es lectura. El problema es evaluar tecnología contra un sistema en marcha — y financiar solo las apuestas que cambian cómo nace el siguiente servicio.

Los atajos entre servicios (Eloquent compartido, un monolito FastAPI para el pipeline de obligaciones, reglas de negocio en el gateway) se ven rápidos y convierten cada cambio posterior en un impuesto de coordinación.

Restricciones

El código de dominio no importa Laravel, Eloquent, Redis ni HTTP. Los casos de uso dependen de ports; Eloquent se queda en adaptadores de infraestructura.

El trabajo nuevo de Laravel va a Application/Slices/{FeatureName}. La lógica nueva de obligaciones en Python va a domain/ y processors/, cableada en consumers/runtime.py. Los workers internos no crecen una API HTTP.

Las denegaciones esperadas de autorización son PolicyDecision + ErrorCode. Las excepciones del framework son para fallos inesperados, no para “este usuario no puede hacer eso”.

Arquitectura

La plataforma es un hexágono por capas: Infrastructure → Application → Domain. Los productos nacen como servicios Laravel con slices JSON:API, o como consumidores Python de streams, no como un framework nuevo por equipo.

Redis Streams es el backbone asíncrono. Payloads y nombres de stream son contratos. La idempotencia se diseña; se asume entrega at-least-once.

La entrega está contenerizada: imágenes Docker, Nginx, Kubernetes, Helm para jobs de migrate. El cluster es el runtime. No define bounded contexts.

Architecture

Soga — reglas de plataforma, servicios de producto

Architecture pack

Slices · contratos · streams

ProCrédito v2

Productos internos

Servicios Laravel

Workers Python

Redis Streams

API Gateway

Kubernetes

Docker · Helm · Nginx

El architecture pack como restricción. Los servicios Laravel y los workers Python nacen de las mismas reglas. Eventos y gateway son los únicos cruces legales.

Decisiones clave

Experiencia personal

Escribir el architecture pack; no copiarlo en cada README

Cuando cambia la regla, cambia el pack. Los README de servicio que reescriben arquitectura hexagonal se desvían y después se contradicen.

Experiencia personal

Laravel para el dominio, Python para el pipeline caliente

Un monolito FastAPI o Django para el procesamiento de obligaciones duplicaría el dominio. Los workers transforman; no se vuelven el sistema de registro.

Experiencia personal

Tratar I+D como una función de liderazgo

Presupuesto, staffing y la siguiente apuesta arquitectónica viven con personas que aún poseen la entrega. Una oficina de arquitectura que no entrega será ignorada.

Trade-offs

Se ganó

Los servicios nuevos empiezan desde los mismos slices, ports y contratos de stream. La investigación tiene un camino a producción, y un camino a “no”.

Se sacrificó

Menos aislamiento entre investigación y la siguiente petición operativa. Cada regla de arquitectura es una restricción que el equipo tiene que seguir pagando.

Experiencia personal

Tecnologías

LaravelPHPPythonRedis StreamsMySQLDockerKubernetesNginxHelm

Resultados

Las reglas de plataforma son las que siguen ProCrédito v2 y los servicios posteriores: Laravel hexagonal, workers Python de streams, contratos, Kubernetes.

El pipeline de obligaciones es la prueba de que el corte funciona: procesamiento de alto volumen sin mover el agregado a un framework de workers.

No se publican aquí headcount, cifras de presupuesto ni conteos de módulos.

Lecciones

La arquitectura en una plataforma interna es sobre todo el arte de decir no con una razón. Eloquent compartido y HTTP-en-workers son los atajos que vuelven como incidentes.

La investigación tecnológica solo sirve si cambia una decisión. Leer sobre una herramienta no es I+D; cambiar la forma del sistema, o elegir no hacerlo, sí lo es.

Un pack que no se usa en el siguiente slice es documentación. Un pack que rechaza un pull request es arquitectura.