forumAbrir tema

Renovamos un sistema heredado de 10 años, el desarrollador propone "microservicios" — ¿es buena idea para un producto pequeño?

SSerkan Ç***VeteranoMiembro de la comunidad
Miembro desde
may 2023
Mensaje
294
#1

Ofrecemos un servicio de software B2B para agencias de logística en EE. UU. Tenemos una app monolítica central desarrollada en 2014 que fue creciendo con parches y añadidos con el tiempo. Unos 1.200 usuarios corporativos activos ingresan al sistema a diario y cargan datos. Mantenerlo se volvió dificilísimo hasta un simple cambio en facturación puede romper cosas por cualquier lado. Por eso asignamos un presupuesto de 70.000 dólares para renovar el sistema desde cero con una infraestructura moderna.

Un programador senior que recién se suma al equipo insiste en que sí o sí debemos pasar a una arquitectura de microservicios montando servicios separados para autenticación, facturación, operaciones y reportes. Pero nuestro equipo es de solo 3 desarrolladores y no tenemos a nadie especializado en infraestructura cloud.

Para un sistema de este tamaño y un equipo de 3 personas, ¿los microservicios son el camino correcto o nos meteremos en una carga operativa inmanejable? En un proceso de modernización de software heredado, ¿cómo encarar la decisión entre microservicios y un monolito bien estructurado?

NNuri G***ParticipanteMiembro de la comunidad
Miembro desde
jun 2025
Mensaje
158
Más útil#2

Respuesta corta: Con un equipo de desarrollo de tres personas y 1.200 usuarios activos, elegir una arquitectura de microservicios es un error operativo. A la escala que tienen hoy no necesitan un sistema distribuido; necesitan un software monolítico moderno, modular, bien estructurado y con tests automatizados.

Los microservicios resuelven un problema de escala organizacional más que de rendimiento del software; es decir, permiten que decenas de equipos de ingeniería desplieguen código sin depender entre sí. Pero a cambio meten una complejidad enorme. Bases de datos distribuidas, latencia de red entre servicios, riesgos de consistencia de datos y debugging distribuido harán que un equipo de 3 personas pase la mayor parte del tiempo gestionando infraestructura en vez de generar lógica de negocio.

En su caso, la hoja de ruta adecuada debería ser: 1) Definir claramente los límites de negocio y limpiar la estructura monolítica separando el código en módulos independientes, 2) Normalizar la base de datos y aumentar la cobertura de pruebas automatizadas, 3) Si surge un proceso puntual que realmente deba escalar por separado o consuma muchos recursos en segundo plano (como la generación masiva de facturas en PDF o reportes pesados), separarlo como un servicio de colas en background. No gasten su presupuesto de 70.000 dólares en orquestación y quilombos de infra, inviértanlo en la calidad funcional del producto.

KKoray C***ParticipanteMiembro de la comunidad
Miembro desde
oct 2022
Mensaje
180
#3

Tu programador probablemente solo quiere sumar arquitecturas de moda a su CV. 1.200 usuarios corren tranquilos en un solo servidor optimizado con una base de datos relacional estándar. Que tres personas intenten mantener microservicios les va a duplicar los tiempos de entrega como mínimo.

TTülay A***Participante
Cargo
Empleado de tienda
Sector
Embalaje
Tipo de organización
Equipo de 8 personas
Miembro desde
dic 2023
Mensaje
64
#4

El año pasado cometimos el mismo error con un equipo de 4 personas. Dividimos el sistema en cinco microservicios y nos pasamos los primeros 6 meses resolviendo fallos de comunicación entre servicios. Las facturas de cloud saltaron de 400 a 2.300 dólares mensuales. Al final volvimos a un monolito modular y la velocidad de desarrollo se triplicó.

SSelinParticipante
Cargo
Desarrollador frontend
Tipo de organización
Empresa de 20 empleados
Miembro desde
feb 2024
Mensaje
164
#5

Pasar a microservicios no es solo tirar código. Tienen que montar service discovery, colas de mensajería, logging distribuido y manejo de transacciones distribuidas. Como además van a partir la base de datos, un simple JOIN de SQL pasa a ser una catarata de llamadas API entre servicios. Si no hay alguien de DevOps dedicado full-time en el equipo, el sistema no va a ser más rápido, todo lo contrario.

FFerhat K***Participante
Cargo
Líder de equipo de desarrollo
Sector
Fabricación de maquinaria
Tipo de organización
empresa dentro de un holding
Miembro desde
ene 2023
Mensaje
377
#6

Para encarar la refactorización sigan estos tres pasos: 1) Limpien el esquema de base de datos actual y conéctenlo directo a la lógica de negocio, 2) Organicen las carpetas del código con la disciplina de microservicios pero manteniéndolo en un solo proyecto (monolito modular), 3) Cierren riesgos antes de salir a producción escribiendo tests unitarios y de integración exhaustivos.

UUfuk S***Veterano
Cargo
Administrador de red
Sector
Fabricación de muebles
Tipo de organización
taller
Miembro desde
oct 2024
Mensaje
187
#7

nosotros nos mandamos con la misma ilusion hace dos años. se caia un servicio y arrastraba a los demas en cadena, seguir los logs era una pesadilla total. con equipo chico el monolito es la gloria cero necesidad de complicarse.

VVildan U***ParticipanteMiembro de la comunidad
Miembro desde
dic 2025
Mensaje
32
#8

¿Y si montamos un monolito y más adelante los usuarios suben a 10 mil o 50 mil vamos a tener que tirar todo a la basura? en fin ¿No le estaríamos poniendo un freno al crecimiento?

PPınar K***Nuevo miembroMiembro de la comunidad
Miembro desde
ago 2026
Mensaje
410
#9

Hasta 50 mil usuarios pueden correr comodísimos en un único servidor bien optimizado. Plataformas SaaS globales gigantescas con millones de transacciones siguen operando sobre arquitecturas de monolito modular. Si el día de mañana hace falta, sacan solo el módulo que haga cuello de botella a un servicio aparte; meter un sistema distribuido desde ahora no aporta nada.

ÖÖmer E***ParticipanteMiembro de la comunidad
Miembro desde
ago 2023
Mensaje
71
#10

Considerando su presupuesto actual y los recursos humanos con los que cuentan, el enfoque más razonable en términos de gestión de riesgos es una arquitectura de monolito modular. Enfocarse en las funciones del producto en lugar de en la complejidad de la infraestructura impactará directamente de forma positiva en el retorno de su inversión.

TTuğçe U***Experto
Cargo
Planificación de producción
Sector
Electricidad-electrónica
Tipo de organización
Empresa de producción de 40 empleados
Miembro desde
ene 2023
Mensaje
174
#11

Voy a detallar un poco el aspecto técnico. Las decisiones apresuradas son las que hay que corregir seis meses después.

Corrijanme si me equivoco.

SSelin S***Participante
Cargo
Propietario de empresa
Sector
Contabilidad y asesoría fiscal
Tipo de organización
cooperativa
Miembro desde
jul 2024
Mensaje
212
#12

es correcto en general pero falta un detalle pero las decisiones apresuradas son las que hay que corregir seis meses después.

AAslı B***Experto
Cargo
Responsable de compras
Sector
Consultoría
Tipo de organización
empresa familiar
Miembro desde
dic 2022
Mensaje
19

Doki · Migración de infraestructura · 2023

#13

este hilo es para archivar.

OOsman D***Experto
Cargo
Director de cadena de suministro
Sector
Construcción
Tipo de organización
Empresa de 120 empleados
Miembro desde
mar 2025
Mensaje
43
#14

Tomo nota, gracias. Que todo el mundo haga algo no significa que sea lo correcto.

También me gustaría saber si alguien lo hace de otra manera.

ZZeynep A***ParticipanteMiembro de la comunidad
Miembro desde
sept 2023
Mensaje
1
#15

tomo nota, gracias.

MMehmet G***Participante
Cargo
Contable
Sector
Formación
Tipo de organización
agencia boutique
Miembro desde
sept 2023
Mensaje
78
#16

Esto también tiene su parte de medición. Los primeros tres meses todo va bien los problemas aparecen en el cuarto.

Si tenéis dudas, escribid, os responderé en la medida de lo posible.

BBora A***Participante
Cargo
Planificación de producción
Sector
Comercio electrónico
Tipo de organización
empresa dentro de un holding
Miembro desde
oct 2024
Mensaje
65
#17

No sabía eso.

EErcan Ç***Participante
Cargo
Diseñador gráfico
Sector
Fabricación de muebles
Tipo de organización
negocio unipersonal
Miembro desde
ago 2023
Mensaje
57
#18

Me pasó lo mismo.

FFatma Ç***Participante
Cargo
Director de producción
Sector
Imprenta
Tipo de organización
cooperativa
Miembro desde
may 2023
Mensaje
27
#19

Hablaré desde el otro lado, yo estoy en el lado del proveedor. Que todo el mundo haga algo no significa que sea lo correcto.

Tomar notas durante dos semanas da mejores resultados que estimar seis meses. Corrijanme si me equivoco.

RRabia Ç***Participante
Cargo
Director de TI
Sector
Energía
Tipo de organización
Empresa de producción de 40 empleados
Miembro desde
jun 2025
Mensaje
354
#20

Permíteme resumir lo que se ha dicho hasta ahora. Si obtienes tres respuestas distintas sobre un tema, la pregunta está mal formulada.

Comprobado por experiencia.

Responder