Monolito o Microservicios: Qué Necesita de Verdad una Pyme

«Microservicios» es una de esas palabras que suenan a decisión profesional. En la práctica, equivocarse pronto de arquitectura cuesta más que casi cualquier otra decisión técnica que vayas a tomar.

La respuesta corta

Si tienes un producto, un equipo pequeño y menos de unos cientos de miles de visitas al mes, empieza por un monolito bien estructurado. Divídelo en servicios solo cuando un problema concreto y con nombre te obligue: ni antes, ni porque suene más serio.

Qué significan de verdad las dos palabras

Un monolito es una única aplicación unificada. Las páginas, la lógica de negocio y el acceso a la base de datos viven en un mismo repositorio y se publican como una sola pieza. Cuando publicas, publicas todo a la vez.

Los microservicios parten eso en muchas aplicaciones pequeñas que se ejecutan, publican y escalan de forma independiente, y que se hablan por red. Las reservas pueden ser un servicio, los pagos otro y el correo otro.

Ninguna de las dos es una nota de calidad. Son compromisos distintos, y cuál es el bueno depende casi por completo del tamaño de tu equipo, no de la ambición de tu producto.

Qué problema resuelven realmente los microservicios

Los microservicios resuelven antes un problema de organización que uno técnico: muchos equipos sobre un mismo producto que se bloquean entre sí. Si cuarenta personas comparten un repositorio y una publicación paraliza el trabajo de todas las demás, dividir el sistema para que cada equipo tenga y publique su parte es una solución de verdad.

Netflix, Uber y Amazon lo necesitan: tienen cientos de equipos. Una empresa en crecimiento con una web, un proceso de reservas y un formulario de contacto no tiene ese problema, así que tampoco puede cobrarse ese beneficio.

Qué te cuestan los microservicios

El coste es operativo y es fácil de subestimar, porque nada de ello se ve en una demo.

• Cada servicio necesita su propio todo. Su despliegue, su monitorización, sus registros, su gestión de errores, sus secretos, sus migraciones de base de datos. Cinco servicios son cinco veces ese trabajo.
• La red pasa a formar parte de tu lógica. Llamadas que antes eran inmediatas y fiables ahora pueden ir lentas, fallar a medias o llegar dos veces. Cada uno de esos casos hay que tratarlo.
• Depurar cruza máquinas. «¿Por qué ha fallado esta reserva?» pasa de leer una traza a correlacionar registros de cuatro servicios.
• Los datos se complican. Una transacción única que abarque varios servicios no viene de regalo; mantener la coherencia se convierte en trabajo de diseño.
• Desarrollar en local se vuelve lento. Levantar el sistema entero en un portátil para corregir un fallo deja de ser trivial.

Para un equipo pequeño, esa carga es un impuesto permanente a cambio de un beneficio que todavía no puede usar.

El error que más vemos

La versión cara no es «elegí un monolito y se me quedó pequeño». Es un equipo pequeño que partió el producto en seis servicios demasiado pronto y se pasó el año siguiente manteniendo infraestructura en lugar de publicar funcionalidad. Mientras tanto, el competidor con un monolito aburrido publicaba cada semana.

Que se te quede pequeño un monolito es un buen problema: significa que tienes tráfico y equipo. Y además tiene solución, siempre que el monolito se construyera con algo de disciplina.

Cómo construir un monolito que puedas dividir después

Esta es la parte que importa. «Empieza con un monolito» solo es buen consejo si ese monolito no acaba siendo un nudo.

• Mantén fronteras internas claras. Organiza el código por dominio de negocio —reservas, facturación, cuentas— y no por capa técnica. Un módulo que puedes describir en una frase es un módulo que podrás extraer.
• Háblate por interfaces, no por dentro. Si el código de reservas entra directamente en las tablas del de facturación, ya los has soldado.
• Una sola base de datos, pero con las tablas apropiadas. Cada dominio posee sus tablas; los demás preguntan, no entran.
• Escribe las pruebas en las fronteras. Serán el contrato el día que conviertas un módulo en servicio.

Haz eso y extraer un servicio será después una semana de trabajo, no rehacerlo todo. Sáltatelo y el monolito sí se convertirá en aquello de lo que la gente te avisa.

Cuándo dividir sí es lo correcto

Hay señales reales. Divide cuando puedas señalar una de estas, no antes:

• Una parte del sistema tiene necesidades de escala completamente distintas: por ejemplo, procesado de vídeo que debe poder saltar a veinte máquinas mientras la web necesita una.
• Dos equipos se bloquean de verdad y de forma repetida al publicar.
• Un componente necesita otro entorno de ejecución u otro lenguaje por una buena razón.
• Una obligación normativa te fuerza a aislar ciertos datos.

Fíjate en que ninguna de ellas es «quizá algún día seamos grandes».

Qué significa esto para tu proyecto

La arquitectura correcta es la más simple que cubre tus necesidades. Pagar por complejidad que no necesitas no es prepararse para el futuro: es solo caro, y frena justo la velocidad de publicación con la que una empresa pequeña puede competir.

Nosotros construimos los proyectos de cliente como monolitos bien estructurados y con fronteras internas limpias, y lo decimos por delante. Tienes simplicidad ahora y un camino claro de crecimiento para el día en que de verdad lo necesites, que en la mayoría de negocios no llega nunca.