¿Microservicios o aplicación monolítica?

Ufff, tengo que decirlo, aunque no les guste, pero en un 90% de los casos lo mejor será desarrollar una plataforma monolítica. Por favor olvídense de los micro servicios. Ya está, fue dicho.

No se trata de gustos o de la moda, sino de ser eficientes y abordar los problemas con soluciones prácticas. Actualmente se escucha mucho acerca de implementar proyectos utilizando microservicios, incluso en empresas pequeñas que están comenzando nuevos negocios.

Haciendo un poco de historia, el 2014 fue el año en que Martin Fowler y James Lewis publicaron un artículo muy innovador en cuanto a un nuevo concepto de arquitectura: microservicios.

Muchas empresas adoptaron esta estrategia, entre ellos Uber y otros grandes de la industria. Sin embargo, al poco tiempo (2016) ya se comenzaron a escuchar charlas como “Lo que me hubiera gustado saber antes de ampliar Uber a 1.000 servicios” por Matt Ranney. Así, el 2020 Uber ya anunciaba su plan para reducir la complejidad de sus servicios. Este plan estaba orientado a agrupar decenas de servicios bajo un mismo dominio para reducir el número de solicitudes entre servidores, y al mismo tiempo migrar los pequeños servicios en unidades de mayor tamaño.

Por otra parte, hace poco (2023), Amazon Prime reemplazó su aplicación de microservicios por una aplicación monolítica reduciendo sus costos en un 90%. ¿Qué tal?

En síntesis, podemos decir de los microservicios. Lo bueno:

• Permitió que distintos equipos de ingeniería y departamentos trabajaran sin estar alineados. Tal cual. Cada equipo podía desarrollar en el lenguaje que más le acomoda, sin importar cómo están trabajando los otros. Este enfoque podría tener sentido cuando existen múltiples equipos de desarrollo.
• Disminuyen las reuniones entre equipos. En lugar de juntarse con otro equipo para integrar tu funcionalidad en un servicio que pertenece a otro equipo —y las inevitables negociaciones, solo creas el nuevo servicio, sin necesidad de coordinarte con otros equipos.
• Puede haber equipos con ingenieros menos experimentados. Un equipo nuevo tiene pocos desarrolladores, así que no es el fin del mundo si los servicios no son muy estables. Los profesionales menos experimentados aprenden y mejoran a base de ensayo y error.

Lo malo:

• Duplicación de servicios. Muchos servicios hacen cosas similares, y al principio esto no es un problema. Pero con el tiempo, puede convertirse en una fuente de frustración constante cuando un equipo construye otro micro servicio para desbloquearse, en lugar de tomarse un día o dos para integrar su caso de uso en el servicio que ya existe.
• Gestión de los servicios. Cuando se tienen de miles de servicios, cuestiones tan sencillas como quién está de guardia para un servicio, la ubicación del código de un servicio o cómo desplegar un servicio se vuelven más complejas. Las pruebas de integración de múltiples servicios no son triviales. Spotify compartió su plataforma Backstage justamente para ordenar la gestión de sus cientos de servicios.
• Complejidad del soporte de los servicios. Cuando un equipo de 7 ingenieros es responsable de 20 servicios, las guardias suelen ser estresantes y difíciles de gestionar.

Un divertido resumen de lo que pueden ser los microservicios lo pueden ver en este sketch de Krazam. Y dicha parodia no se aleja mucho de la realidad.

En pocas palabras, los beneficios de los microservicios sólo son visibles cuando la empresa tiene “hipercrecimiento”, pero no cuando está tratando de alcanzar dicho peak. En las etapas previas conviene consolidar los servicios, sobre todo cuando sólo hay un equipo de ingenieros.

Por el contrario, las aplicaciones monolíticas pueden significar una apuesta más segura cuando no se espera crecimiento, o el tráfico no es del 1 millón de usuarios concurrentes. Las ventajas y desventajas de las soluciones monolíticas suelen ser opuestas a las de los microservicios. Las plataformas monolíticas funcionan mal cuando se incorporan un gran número de nuevos desarrolladores, porque todos se pisan los unos a los otros. Pero funcionan bien cuando hay un buen ritmo de desarrollo y despliegue, siempre que el equipo no crezca demasiado rápido.

He escuchado relatos sobre el dolor de tener demasiados microservicios después de profundos recortes de personal. Una Fintech que contaba con +800 empleados en su mejor momento, incluidos 200 ingenieros, realizó despidos masivos y redujo su plantilla a unos 500 empleados, con menos de 150 ingenieros. Hoy en día, los microservicios son un gran problema operativo. De un ingeniero de esta empresa:

"Todavía tenemos unos ~400 servicios que mantener, ¡a pesar de que ahora tenemos menos de 2/3 de los profesionales que teníamos en 2021, cuando construimos todos estos! Hace poco le dijimos a la Gerencia: "No tenemos suficientes personas ni siquiera para operar estos servicios: necesitamos contratar más". La respuesta fue: "Arréglalo. ¿Quizá usar IA?".

Por supuesto que nadie debería optimizar una plataforma para luego despedir al 40% del personal, pero las empresas con arquitecturas más simples ven la sobrecarga operativa como un problema menor cuando hay menos personal, que aquellos que deben mantener miles de microservicios.

Para que quede claro, un sistema que está siempre creciendo traerá dolores de cabeza, y modularizar un sistema monolítico si es un desafío. Khan Academy invirtió 3,5 años en dividir su monolito en varios microservicios. En el fondo, el enfoque es introducir una arquitectura de microservicios cuando ya existe la necesidad, más que comenzar con la complejidad porque espero que en el futuro sea útil.