¿Los microservicios están mal, o tú te equivocas?

Por que hacer esta pregunta sobre microservicios y arquitectura de software

Este articulo nace tras leer otro texto donde se explicaban comunicaciones entre servicios en sistemas que se presentaban como microservicios pero que en realidad eran macroservicios de dominio. La confusion es habitual y conviene aclararla.

Un poco de historia de los servicios

Los sistemas basados en servicios existen desde hace mas de 30 anos. Durante los 90 y los 2000 se hablaba de servicios de dominio y tambien se construian monolitos distribuidos cuando el proceso era pequeno sacando las conexiones a base de datos del monolito y sustituyendolas por llamadas de red a un modulo servidor. Hubo epocas de SOA con buses ESB para integrar legados. En 2012 algunos desarrolladores propusieron dividir servicios de dominio en unidades mucho mas pequenas y desplegables de forma independiente y a eso lo llamaron microservicios. La idea era sencilla, pero la practica se complico.

La mezcla de conceptos

A partir de 2014 se puso de moda hablar de microservicios y desde el mundo dotnet empezo a denominarse microservicios a cualquier sistema basado en servicios, creando la falsa dicotomia monolito frente a microservicios. En la realidad existen monolitos y sistemas distribuidos, y dentro de estos ultimos hay muchas variantes. No todo sistema distribuido es basado en servicios y no todo servicio es micro. Para diferenciar, es util hablar de macroservicios para los grandes servicios de dominio y reservar microservicios para funciones muy pequenas e independientes. Un ejemplo real: DoorDash afirmo que al pasar del monolito a microservicios creo mas de 500 servicios y una orden toca mas de 100. Eso si son microservicios de verdad, cada uno creado y desplegado de forma independiente.

El problema habitual

Muchos equipos que en realidad construyen macroservicios importan conceptos pensados para microservicios, como el bounded context y las comunicaciones intensivas entre servicios. El bounded context surgio para gestionar quien puede cambiar que parte del modelo y evitar impactos cruzados entre equipos, mas como gestion de personas que como necesidad tecnica. En macroservicios suele ser innecesario introducir comunicaciones interservicio complejas. En microservicios son el punto debil y conviene minimizarlas; en macroservicios introducirlas por imitacion es un error. Otro fallo frecuente es interpretar los diagramas de microservicios como bases de datos separadas por servicio. En un relacional lo correcto suele ser separar por esquemas dentro de una misma base, no por bases diferentes. Dividir en bases por dominio sin una estrategia clara de particionado vertical y despliegue independiente suele ser una mala idea.

Importa de verdad

La doble interpretacion de microservicios lleva una decada entre nosotros y no es facil cambiarla. Lo importante es evitar trasladar practicas necesarias en microservicios a contextos de macroservicios donde solo anaden complejidad sin beneficio. Entender el panorama completo ayuda a elegir con criterio.

Sobre arquitectura de software

Si te interesa profundizar, te recomiendo este sitio y en especial un resumen de 10 minutos. Escuchar a profesionales con decadas de experiencia suele ahorrar muchos disgustos.

Hay una alternativa mejor

En proyectos con macroservicios he utilizado peticiones compuestas. Por ejemplo, al iniciar una aplicacion cargo varios conjuntos de datos en una sola respuesta en formato json. Para crear un pedido de un cliente nuevo envio en un unico mensaje los datos del cliente, direcciones, pedido, lineas, pago y actualizaciones de stock, y el servidor lo procesa en una o dos transacciones. En terminos de carga de red, esto reduce el numero de viajes y hace que la medida TPS no refleje bien el trabajo util realizado, porque con menos transacciones por segundo se resuelve mas logica de negocio.

Y ademas

Tras varias conversaciones con otros desarrolladores, construimos un servidor basado en scripts donde cada script maneja un endpoint y es totalmente independiente del resto. Se pueden anadir o cambiar sin afectar a otros. Se consigue el objetivo de independencia sin desplegar cientos de procesos. Con una sola instancia de servidor hemos convertido la solucion en un monolito distribuido, y para trabajos centrados en base de datos se comporta mejor que macroservicios o microservicios, manteniendo la posibilidad de escalar con multiples instancias cuando haga falta.

Como te ayuda Q2BSTUDIO

En Q2BSTUDIO te ayudamos a elegir la arquitectura adecuada para tu caso, ya sea monolito bien modular, monolito distribuido, macroservicios o microservicios reales. Disenamos y construimos aplicaciones a medida y software a medida con enfoque en rendimiento, mantenibilidad y despliegue continuo. Si tu estrategia pasa por la nube, contamos con servicios cloud aws y azure para observabilidad, automatizacion de despliegues, arquitectura de eventos y seguridad avanzada.

Nuestro diferencial

Somos especialistas en inteligencia artificial e ia para empresas, disenamos agentes IA que se integran con tus procesos, reforzamos tu postura de ciberseguridad con evaluaciones y pentesting, e impulsamos decisiones con servicios inteligencia de negocio y power bi. Tambien automatizamos procesos de punta a punta y aseguramos que tu arquitectura soporte el crecimiento sin incrementar innecesariamente la complejidad.

Conclusiones accionables

Antes de dividir en microservicios, confirma si necesitas independencia de deploy por funcion, escalado granular y equipos alineados por servicio. Si no, considera macroservicios o un monolito distribuido bien disenado. Evita comunicaciones interservicio innecesarias, aplica bounded context con criterio organizativo y no fragmentes la base de datos sin una estrategia clara. Y si buscas una hoja de ruta pragmatica, en Q2BSTUDIO podemos evaluar tu arquitectura y proponer un plan orientado a valor real con aplicaciones a medida, inteligencia artificial, ciberseguridad y servicios cloud.