Por qué no deberías montar microservicios
Vicent Soria Durá
CTO y estratega en ahorro de costes: Elevando la rentabilidad mediante soluciones ZeroWaste en infraestructura cloud
La arquitectura de microservicios se empezó a poner de moda hace unos años, ¿allá por 2013?.
Todo el mundo quería hacer microservicios. ¡Como Google! ¡Netflix! ¡Uber! Si no hacías microservicios no eras nadie.
La realidad es que no eres Google, ni Netflix, ni Uber. Me atrevo a decir con un margen de confianza del 95% que tú no necesitas microservicios.
Los microservicios añaden mucha complejidad accidental, y por tanto, debemos tener la seguridad de que este incremento de complejidad tiene algún otro beneficio.
Si tienes un equipo técnico de 2-10 personas (el 80% de los que me he encontrado) está absolutamente injustificado este tipo de arquitectura. La sobrecarga que implica no compensará (prácticamente) nunca.
Os lo muestro con un ejemplo reciente:
Un cliente al que hemos ayudado a actualizar todo su sistema y a resolver un problema serio que les provocaba una caída total del servicio cada 1-2 semanas (que parecía de forma casi aleatoria).
Esta empresa tienen del orden de 20-25 microservicios.
El equipo técnico actual es de 2 personas.
Recomendado por LinkedIn
Volver a hacer funcionar pipelines de CI/CD (que en algunos casos nunca habían funcionado) nos ha llevado del orden de 1 o 2 por día. Con unos números grosso modo, podemos ver que esto nos ha llevado unos 10 días de trabajo (no todos los microservicios requerían esta actualización, ya que algunos eran simples proxies).
Si tuviéramos un único monolito (y quizás algún servicio auxiliar), el trabajo se habría reducido a 1 o 2 días.
Esto tiene una consecuencia adicional, y es que las dependencias de los proyectos se quedan desactualizadas, porque lleva demasiado trabajo hacer tantos cambios. La consecuencia final es que pueden aparecen problemas de seguridad y quedar expuestos a ataques malintencionados.
Ya no hablemos de latencia, service discovery, tracing, ...
Me dejo temas, pero creo que ya veis por donde voy.
Con este artículo no quiero decir que nunca se deban usar microservicios. En absoluto. Lo que quiero decir es que esta arquitectura tiene un coste (bastante grande, en mi opinión), y tendría que estar justificada su adopción. No podemos montar estas cosas "porque está de moda" o "por aprender". Tenemos que ser un poco responsables con las decisiones que tomamos.
Para aclarar: Tener múltiples servicios usando la misma base de datos no es microservicios. Tener un monolito y varios servicios auxiliares tampoco es arquitectura de microservicios. Los workers tampoco son microservicios.
Otro día ya hablaremos de kubernetes y las barbaridades que se están haciendo ;)
Senior Software Engineer
2 añosPara mi la solución óptima pasa casi siempre por servicios/monolitos asíncronos (por colas) compartiendo base de datos. Hacerlo así aporta aislamiento de equipos. Ejemplos: login, checkout, dashboard, etc
Senior Software Engineer at Tetrate
2 años100% de acuerdo. La mayoría de veces una arquitectura de microsevicios resuelve un problema organizacional. Me atrevería a decir que con menos de 12-15 ingenieros no tienes ese problema. Sí lo veo justificado, en caso de ser pocos ingenieros, en empresas donde incorporar un nuevo lenguaje de programación te va a dar un 10X factor en algo. Podría ser desde performance puro (he visto 500x en mi anterior trabajo generando PDFs pasando de Ruby a Go) hasta captación de talento (i.e extraer subdomains implementados en monolito en una tecnología "antigua" con deuda técnica a algo más moderno). Ahora bien, si tienes green-field, equipo pequeño y haces microservicios te vas a gastar más tiempo/dinero en operaciones que en ser competitivo implementando los casos de uso de negocio de manera ágil.