¿Otro microservicio? NO, gracias

Suele pasar en este mundo de la tecnología que, cada cierto tiempo, tenemos a todo el mundo hablando y usando determinada solución, producto o herramienta, sin ninguna otra razón de peso  mas que la moda, o que el "main stream" de turno dice que es la forma correcta de hacer las cosas.

Entre esas tecnologías o soluciones de moda nos encontramos con los ya harto renombrados, microservicios. Todo el mundo habla de ellos, todo el mundo migra hacia ellos, ... pero, y siempre hay un pero, ¿son en verdad tan beneficiosos los microservicios? ¿Cuanto hay de mito y cuanto de, ¿fea?, realidad?

Como ya es costumbre por estas lides, siempre empezamos con los conceptos, así que manos a las sobras!!!

¿Qué son los microservicios? 

Los microservicios son un patrón de componentes, en el que cada componente se construye, despliega y ejecuta como un servicio independiente, atómico en su funcionalidad; lógica y modelo de datos.
Noten que dije que son un patrón de diseño, de construcción, de despliegue y de ejecución... pero No usé, ni pienso usar, el término "Arquitectura" para referirme a los microservicios, puesto que tal arquitectura simplemente NO EXISTE.

Los microservicios son útiles únicamente cuando se necesita escalamiento horizontal masivo e independiente. Sí sus necesidades de escalamiento son ínfimas, entonces Ud. no necesita microservicios. Así de simple.

Beneficios mitos que ofrece este patrón

Vamos a revisar ahora los supuestos beneficios que normalmente se le atribuyen a este modelo de componentes.

Código más complejo limpio

No se necesita introducir una capa extra de red en nuestra plataforma para tener código mas limpio y elegante.

La cruda verdad es que la limpieza, la elegancia y la calidad del código no tienen nada que ver con el modelo de solución o patrón de componentes que se esté usando. Todo lo antes expuesto depende en última instancia de la disciplina del equipo de desarrollo y las buenas prácticas férreas que se imponga el equipo.

Son más fáciles complejos de implementar

Las transacciones distribuidas NUNCA son fáciles de implementar

Aunque la idea de que los microservicios modelan componentes aislados es atractiva, y sugiere que, al implementar cada componente por separado como un módulo independiente,  deben ser estos últimos más fáciles de construir, desplegar y ejecutar. Pero la verdad es que todo lo antes expresado parte de un supuesto erróneo, y es el que asume que los dominios de negocio o los ámbitos de cada componente están bien definidos y separados. En el mundo real se necesita hacer un enorme trabajo de diseño y análisis y, apuesten que es así, mas de un pequeño "truco" para definir en forma separada los dominios de negocio y por ende de cada componente. Eso sin contar con que tarde o tempano vamos a necesitar lidiar con la tarea de orquestar varios microservicos con el propósito de completar transacciones distribuidas de mediana o larga duración.

Es cuando se trata de orquestar transacciones distribuidas que la complejidad introducida por los microservicios se hace evidente y fracasa miserablemente en la mayoría de los casos.

Nuevamente, cuando se lidia con transacciones distribuidas es cuando más disciplina se necesita, a todo nivel.

Son más rápidos pesados

Sí una JVM es lenta, varias JVM lo son aún mas

Cada componente por separado e independiente presenta una ventaja a la hora de necesitar y hacer uso del escalamiento horizontal, allí es donde los microservicos se lucen!!, pero ¿cuantos de nosotros tenemos necesidades de escalamiento masivo? al estilo de Netflix, ¿cuantos? levanten la mano, a ver, uno, dos, tres de entre 3 mil. Ahora imagine que cada componente de su patrón de solución necesita su propia JVM, cada JVM necesita ser iniciada antes de poder usarla, cada JVM consume sus propios recursos... como ven, todo esto aporta poco a la "rapidez"general de nuestra plataforma, salvo los contados casos de escalamiento brutal.

Para variar, con un poco de disciplina y buenas prácticas de diseño se puede lograr un mejor desempeño sin necesidad de recurrir a los, de por sí complejos, microservicios. 

Mas simples para los ingenieros y desarrolladores

Sí sólo debo atender mis asuntos, lo que le pase a los demás no es de mi incumbencia

Cuando tienes un grupo de ingenieros y demás personas de IT atendiendo tan sólo lo que les compete, es muy frecuente que aparezca el síndrome de "No es asunto mio", en otras palabras, se dificulta en sobremanera la coordinación de los objetivos, reglas y demás buenas practicas entre los diferentes equipos.

Un poco de disciplina ayuda mucho en la consecución de este beneficio en ambientes no basados en patrón de microservicios.

Mejores para el escalamiento

Se pueden escalar microservicios tal como se puede escalar los módulos de un monolítico

Puede parecer contradictorio que critique al final el único beneficio real que ofrecen los microservicios, pero déjenme aclarar un poco la idea, la ventaja en escalamiento de los microservicios no viene tanto de su naturaleza como de las herramientas y tecnologías que los soportan. Sin Docker o Kubernetes, es poco lo que los microservicios hacen por el escalamiento, de hecho se pueden obtener beneficios similares usando las mismas tecnologías con módulos de un monolítico.

Conclusión

Toda la complejidad y costos ocultos que aportan los microservicios sólo se justifican bajo circunstancias muy especiales, y la moda no es una de ellas. Todos los aparentes beneficios de ese patrón de componentes se pueden alcanzar con disciplina y buenas practicas en la mayoría de los casos.
De hecho, todo ese "terror tecnológico" es sólo otro burdo intento de superar la disciplina con herramientas innovadoras de tecnología.

Por último les dejo un par de enlaces para profundizar sobre el tema...

La muerte de la locura de los microservicios y The ugly truth.