Ir al contenido principal

¿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.


Comentarios

  1. En gran parte te doy la razón, hoy en día se usa los Microservicios únicamente por moda y realmente no tienen en cuenta tanto la infraestructura ni las consecuencias en devops. Pero creo que exageras, los microservicios pueden traer beneficios no solo para escalar, sino que al momento que realices un despliegue no afectar otros módulos, tambien te puede dar independencia de equipos, creo que lo enfocas mucho a algo limitado como un sistema, pero los microservicios vienen bien cuando tienes sistemas separados, equipos de desarrollo independientes y ayuda mucho para que los desarolladores se adueñen de la funcionalidad, al mismo tiempo puedes utilizar distintas tecnologías por ejemplo un servicio en Java otro en NodeJS e incluso en distintas versiones de java, en fin hay otras razones buenas del porque si usarlos.

    ResponderEliminar
  2. Dejo URL con caso de Ejemplo en Amazon: https://www.infoq.com/news/2023/05/prime-ec2-ecs-saves-costs/

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

El Melange todavía corre

Ese era el estribillo de un capítulo de unas de mis series favoritas de la infancia, Meteoro o Speed Racer. En ese capítulo un auto “fantasma” el X-3, aparecía de imprevisto y dejaba a todos asombrados con su rendimiento y prestaciones y volvía a desaparecer. Traigo ese episodio a colación puesto que recientemente sostuve una amena charla con un querido amigo, en la que el me manifestaba como los Mainframes habían muerto, o mejor dicho, el concepto de la computación distribuida basada en Mainframes había desaparecido. Para variar, yo no estuve de acuerdo, y le dije que por el contrario, el modelo de computación basado en Mainframes está mas vigente que nunca. Estos fueron mis argumentos:

Primeros pasos con Camunda BPM – Modelando un Proceso BPMN 2.0

Tenemos entre manos la tercera publicación de nuestra serie sobre la Plataforma de BPM de Camunda .  El día de hoy vamos, por fin, a empezar a modelar o construir nuestro primer proceso sencillo en notación BPMN 2.0. Para ello vamos a usar el modelador o editor que ya hemos instalado en nuestra primera publicación , y vamos a guardarlo en la sección de recursos del proyecto Maven Java que configuramos en la segunda publicación . Así que, como ya es costumbre, manos a las sobras…

Como configurar jBPM para usar nuestra propia Base de Datos en un sólo paso

Llevo un buen rato trabajando con jBPM en su serie 6.x, y mi opinión sobre este producto en la versión mecionada no ha mejorado para nada. Es una herramienta plena de funciones y caracteristicas avanzadas, pero tambien está llena de Bugs y es realmente inestable, sobre todo en el ambiente de modelamiento.  Así mismo, debo decir que tiene una muy aceptable API REST y que el motor de procesos y la consecuente ejecución de los procesos es estable y bastante rápida. En esta publicación daré inicio a una serie de artículos que hablan sobre ciertas configuraciones comunes e importantes que se hacen con jBPM. Hoy iniciamos con la configuración de jBPM para que use nuestra base de datos favorita. Esto tiene sentido porque el producto viene con la base de datos H2 por omisión, la cual es excelente para pruebas y evaluaciones rápidas de la herramienta, pero es completamente inaceptable en un ambiente de desarrollo, QA o producción cualquiera. Así que manos a l