Por Qué Ya No Uso Microservicios
Descubrí los microservicios en una etapa muy temprana, y no tardé en quedar maravillado con todos los beneficios que esta arquitectura prometía para las empresas. Sin embargo, hace años que ya no la elijo para mis proyectos nuevos porque, en la práctica, los costos suelen superar los beneficios.
1. Caro, muy caro
Cualquiera que haya visto una factura de AWS con una arquitectura de microservicios sabe de lo que hablo. Lo que tiene de sofisticada, lo tiene de costosa. He visto facturas de varios miles de dólares que podrían haberse reducido a unos pocos cientos si se hubiera optado por una arquitectura monolítica. ¿Qué lo encarece tanto? Cada servicio, por más pequeño que sea, tiene requisitos mínimos de hardware que, al multiplicarse, inflan el costo rápidamente. Además, la orquestación y comunicación entre estos servicios suman otros tantos dólares a la cuenta final.
2. Costoso para desarrollar
Lo que es beneficioso para las grandes empresas, es doloroso para las más pequeñas. En una compañía grande, tener pequeños servicios agiliza el ciclo de delivery. Sin embargo, para una startup con un equipo reducido, mantener y desarrollar numerosos servicios se vuelve mucho más caro, ya que una sola persona puede terminar manteniendo múltiples microservicios a la vez.
3. Complejo para debuguear
Un bug en producción puede convertirse en una pesadilla con microservicios. Una sola solicitud de usuario puede pasar por varios servicios, lo que hace que la trazabilidad sea muy compleja. Además, replicar el caso en un entorno local de desarrollo es, en muchos casos, prácticamente imposible.
4. Latencia exagerada
La idea de que cada microservicio sea una caja negra donde lo único relevante es su API suena genial. Sin embargo, en la práctica, la comunicación entre microservicios suele ser desastrosa en términos de tiempos de respuesta. No importa lo bien diseñado que esté nuestro sistema, la experiencia del usuario es innegociable.
5. Baja reutilización de código
Cada microservicio tiene su lógica encapsulada. ¿Qué sucede cuando necesitamos reutilizar código entre servicios? He visto muchas veces cómo se termina duplicando el código. Otras veces, surgen bibliotecas “commons” o “utils” que se convierten en una bolsa de gatos donde cualquiera mete cualquier cosa, y muchísimos microservicios dependen de ellas, con los pros y contras que esto implica.
6. Difícil de actualizar
El día que se necesita, por ejemplo, aplicar un parche de seguridad a una dependencia común a casi todos los microservicios, hay que recorrer uno por uno, actualizar la dependencia, pasar por el ciclo de release correspondiente y monitorear la puesta en producción. Ahora, multiplica esto por la cantidad de microservicios que tengas.
7. Ah pero Netflix…
Cada vez que algún impertinente cuestiona la arquitectura de microservicios, aparece el comentario típico: “Ah, pero Netflix tiene miles de microservicios y no se quejan”. Sí, es cierto, pero nadie más es Netflix excepto Netflix. De hecho, es muy poco probable que tu empresa necesite algo remotamente parecido. Para la mayoría de las startups, pagar el costo de tener una arquitectura sobrada de este tipo significará la quiebra.
Larga vida al monolito.