Desde que comenzamos a escuchar el término microservicios muchas han sido las conversaciones que se han desencadenado acerca de su idoneidad, de sus ventajas, de sus implicaciones, pero, sobre todo, acerca del tamaño. El hecho de que se llamen micro-algo, lleva a muchos a pensar que un microservicio debe ser eso, micro. Cuando realmente lo que hay detrás de todo eso es mucho más complejo y amplio. En este post intentaremos entender qué quiere decir el tamaño cuando hablamos de servicios.

En esencia los microservicios son una estrategia arquitectónica que busca la agilidad en el desarrollo de software, a partir de dividir los alcances funcionales de un producto, de manera que cada agrupación funcional pueda ser desarrollada, evolucionada, desplegada y mantenida, independientemente de las demás, y soportada por un equipo especializado en dicha parcela funcional del negocio. Ahora, la clave está en definir correctamente esas separaciones o particiones que hacemos de la solución técnica, de manera que no incurramos en problemas que anteriormente (cuando todo estaba unido en un monolito) no teníamos. Veamos pues las diferencias que encontramos entre un monolito y un microservicio.

Monolito o microservicios

Comencemos por analizar una supuesta situación en la que se trata de buscar la mejor solución para un negocio complejo en el que existen muchos procesos. Los procesos tienen cierta independencia entre ellos, aunque también dialogan, y el correcto funcionamiento global depende de la perfecta coreografía de todos ellos. ¿Cuál sería la mejor solución arquitectónica para este caso?, ¿una solución basada en un monolito o una solución basada en microservicios? Veamos la diferencia de ambas opciones desde 9 ejes:

Veamos ahora la comparativa:

De la tabla anterior se desprende que, en el caso de tener un negocio con muchos procesos que han de ser soportados por una solución tecnológica, es preferible que dicha solución esté diseñada mediante una arquitectura de microservicios. Veamos por qué:

Separación de funciones técnicas

Facilidad de evolución

Especializar los equipo por procesos de negocio

Quantum

Monitorización técnica

Latencia

Consistencia de la información

Observabilidad funcional

Automatización

Como primera conclusión podemos decir que, en el caso de desarrollar una solución tecnológica que soporte numerosos procesos de negocio que tienen una dependencia relativa entre ellos debemos optar por una arquitectura basada en microservicios, pues favorece la adaptabilidad.

Esta explicación también justifica la transformación de un gran monolito en varios microservicios con el objetivo de mejorar la adaptabilidad de los procesos de negocio que lo requieran.

Ahora bien, qué quiere decir una dependencia relativa: dos procesos de negocio pueden implementarse en microservicios diferentes en tanto en cuanto acepten consistencia eventual para los datos que comparten y la latencia no sea un inconveniente.

Microlito o microservicios

Veamos qué pasa cuando nuestro problema de negocio consiste en pocos procesos y no requiere de grandes cantidades de código:

Para empezar, como no es un problema complejo (pues consiste en pocos procesos sencillos de negocio) ya no podemos decir que tenemos un monolito, en todo caso sería un microlito (un monolito pequeño).

En este caso, se puede observar en la tabla que la situación cambia. Ahora vemos que el microlito sí permite la especialización del único equipo que lo mantiene, porque son pocos procesos de negocio. Cómo tenemos poco código, la evolución de cada módulo es más sencilla y el quantum es pequeño. Sin embargo, los microservicios siguen presentando los mismos inconvenientes que que en caso anterior. Y la monitorización técnica sigue siendo más sencilla en el caso de los microservicios.

Ahora, cabe hacerse una pregunta: ¿no es verdad que el comienzo de todo desarrollo de software siempre empieza incrementalmente, proceso de negocio a proceso de negocio, de manera que siempre se comienza por soluciones pequeñas?

A partir de aquí podemos deducir la siguiente conclusión: el comienzo del desarrollo de una solución de software debería iniciarse siempre por un microlito y la labor de los arquitectos será estar pendientes para tomar la decisión de escindir el microlito a microservicios cuando este vaya cogiendo tamaño y hacerlo en el momento adecuado. ¿Cuándo es el momento de adecuado? Cuando el microlito comience a convertirse en un monolito, es decir cuando se degrade el time to market o la frecuencia de despliegue o cuando la complejidad funcional no pueda ser abordada por un único equipo y merezca la pena introducir la complejidad añadida por la consistencia eventual, la observabilidad y la latencia.

Conclusiones

Las soluciones para problemas de negocio consistentes en multitud de procesos tiene sentido que se implementen mediante una arquitectura basada en microservicios, pues con ello aseguramos la adaptabilidad.

Las transacciones y allí donde no se pueden asumir los problemas derivados de la consistencia eventual deben estar implementadas en el mismo microservicio.

El comienzo del desarrollo de una solución tecnológica debe partir de un microlito, y mantener siempre la posibilidad de crear otros microlitos/microservicios alrededor del primero o, incluso, la posibilidad de partir el primero en varios microservicios cuando la complejidad aumente y lo permita la consistencia y la latencia.

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete