Mi experiencia

Recuerdo que cuando empecé a trabajar en IT, el mundo de los microservicios estaba en auge. Miles de tutoriales y cursos explicando CÓMO crear aplicaciones con microservicios y conectarlos entre sí, mejorando la arquitectura del sistema y desacoplando monolitos. Todavía recuerdo los posts hablando mal de monolitos y cómo esa arquitectura iba a morir en algún momento.

Imaginate lo que es para un joven que recién empieza, tener que leer ese tipo de titulares. Ahí nomás tiré todo lo que había aprendido en la carrera y me dediqué a aprender y "evangelizar" sobre el uso de microservicios. Para mí era la solución que encajaba en todo. 

Con el paso del tiempo, hablando con ingenieros y desarrolladores, me di cuenta de que había comprado el enfoque incorrecto: "No hay buenas ni malas arquitecturas, sino arquitecturas mal desarrolladas".

Decidi crear un post donde pudiera contarte a vos, que estas leyendome del otro lado, lo que no te cuentan sobre los microservicios y el por que no siempre son la solucion a tu problema

1. Latencia

Cuando todo está dentro de un mismo proceso (como pasa en un monolito), los tiempos de respuesta son casi inmediatos. Pero cuando tenés 15 servicios hablando por HTTP, el tiempo ya no depende de tu código… sino de toda una red que no controlás.

• Cada comunicacion es un posible timeout
• Cada llamada una fuente nueva de errores
• Y cada retry que se tenga que hacer es un golpe directo al rendimiento de tu aplicación.

2. Mas infraestructura que funcionalidad

Pasas de tener un solo servicio  backend a necesitar:

• Service mesh
• API Gateway
• Discovery Service
• Observabilidad distribuida
• CI/CD por servicio
• Control de versiones por contrato
• Dashboards por separado para controlar el rendimiento de cada servicio

¿Y lo mejor? Todo esta inversion antes de que el sistema supere los 300 usuarios

3. Hacer debug se convierte en un trabajo para Sherlock Holmes

¿Tenés un error en tu monolito? Levantas el servicio localmente y reproducís las condiciones para dar con el problema. Un servicio y a lo sumo asegurar la conexión a sus dependencias (Redis, DB, Message Broker, etc.).

Con microservicios la cosa seria algo asi:

• ¿Fallo servicio A o B?
• ¿O fue un timeout de C que tenía que darle respuesta a B para que este responda a A?
• ¿Se habrá reiniciado el contenedor por OOM para el servicio F?

Welcome to the distributed debugging!! 

4. La comunicacion entre equipos

Eso que antes se daba por hecho porque todos trabajábamos sobre la misma base y el mismo servicio, ahora es vital.

Si los equipos no documentan, versionan contratos, entienden dependencias y se hablan entre ellos, terminas con un Frankenstein hecho a medias y que a duras penas funciona y cumple con los requerimientos de producto.

5. Mas tiempo invertido en arquitectura que entregando features

Trabajar con microservicios es tener siempre las mismas discusiones:

• ¿Va en este dominio o en este otro?
• ¿Debería ser un microservicio separado?
• ¿Necesita caché? ¿Otra DB? 
• ¿Que pasa si se cae?

6. Stack costoso

Más servicios implican más procesos/contenedores, lo que implica máquinas más grandes o mayor número de ellas. Lo que se termina traduciendo en más plata invertida.

¿Entonces, no vale la pena?

No, no me malinterpretes. El objetivo de este post es hablar de todo aquello que no te dicen de los microservicios.

Es una arquitectura, a mi entender, muy buena pero que es aplicable en ciertos escenarios:

• Equipos grandes
• Dominios bien definidos
• Trafico real que justifique aislar operaciones
• Tenes resuelta la observabilidad y la cadena de CI/CD
• Tenes tiempo para pagar la complejidad 

Si no cumplís esto… probablemente estás mejor con un monolito modular bien dividido.