Los 4 niveles de madurez de un ecosistema de microservicios

Si tuviera que definir el concepto de microservicio, seguramente diría que un microservicio es un sistema autónomo que tiene la capacidad de resolver una lógica dentro de un dominio, siendo un dominio, un conjunto de funcionalidades que tienen una relación estrecha de negocio.

A partir de ahí, he hablado con organizaciones que entienden que un gestor de contenidos que administra su web es un microservicio dentro de su ecosistema de software y otros que entienden que un microservicio ejecuta sólo una operación de negocio... Posiblemente sea sólo un tema de nomenclatura o simplemente sea el eterno problema de la arquitectura de software de definir cuál es la granularidad. A otro nivel, pero cuando diseñaba arquitecturas bancarias en Java, también existía ese problema de la granularidad en cuanto a los servicios en forma de funciones. Tal vez soy demasiado práctico, pero con el tema de la granularidad, al final, se trata de encontrar una solución que te facilite la vida.

En el tema de los microservicios, diría que ambas cumplen la definición pero, podemos decir que ¿ambos son microservicios? ¿Alguno de mis dos clientes está equivocado? o por lo contrario ¿ambos están en lo correcto (siempre y cuando corran en contenedores docker)?

A continuación os voy a exponer un modelo de madurez de ecosistema que soportaría ambas definiciones de microservicio y algunos puntos intermedios. De hecho, el modelo que os expongo a continuación permite catalogar cualquier ecosistema de microservicios, entendiendo microservicios como lo definido anteriormente.

Un modelo de madurez establece patrones mediante los cuales podemos catalogar un sistema. En nuestro caso, vamos a catalogar un ecosistema (o infraestructura) de microservicios en cuatro niveles diferentes. Estos 4 niveles de madurez establecerán en base a las características técnicas como operativas de los diferentes microservicios.

Al subir en la pirámide de madurez, se perderá flexibilidad en el desarrollo pero se ganará control operativo del sistema y una clara mejora de la visión global de los diferentes microservicios. Esa mejora de la madurez nos permitirá aplicar acciones estratégicas, nos simplificará las migraciones de infraestructura y nos ayudará a detectar problemas operativos.

A mi entender, el uso de microservicios és la clara aplicación del divide y vencerás, pero un director de ingeniería de software deberá encontrar el equilibrio entre la operabilidad, la mantenibilidad, la escalabilidad, el time-to-market y el coste. Por lo que, si se trabaja con microservicios, es necesario establecer objetivos de madurez para el ecosistema que se alineen con los objetivos de la compañía.

Entenderemos que un ecosistema de microservicios es anárquico cuando se componen de subsistemas autónomos ejecutándose en máquinas (físicas o virtuales) diferentes o compartidas (pero sin contenedores). En este punto no existe ningún sistema estándar de integración entre los diferentes microservicios aunque cada uno publica su sistema y el resto de servicios lo consume según sus necesidades.

Cada microservicio es administrado de forma independiente y no existe ninguna normativa técnica que los regule. A nivel interno cada microservicio puede contener su propio panel de administración, su propia base de datos, su propio filesystem e incluso su propia interfaz de administración en línea de comandos. A nivel global, pueden existir elementos de BigData y/o BI que nos permitan obtener información de forma global y elementos de bus de servicios que pueden aglutinar las APIs publicadas por los diferentes micrsoervicios.

Este tipo de sistema tienen una operativa compleja y suelen requerir un equipo con profesionales especializados en diferentes tecnologías. La monitorización suele ser a nivel de sistema operativo y el departamento de operaciones está altamente limitando en cuanto a capacidad operativa.

Podemos decir que los sistemas empresariales de toda la vida, son un ecosistema de microservicios anárquicos. Cada uno tiene su función y existe algún tipo de integración entre ellos.

Puntos fuertes:

• Este tipo de ecosistema es el fuerte desacople que existe entre los microservicios.
• Permite utilizar soluciones completas (opensource y comerciales) como parte del ecosistema reduciendo substancialmente el time to market y el coste productivo.
• No es necesaria una infraestrcutura de contendores.

Puntos débiles:

• Complejidad elevada operativa y evolutiva.
• Dependencias fuertes entre desarrollo y operaciones.
• Necesidad de disponer de gran variedad de skills en desarrollo y operación.
• Falta de estándares de integración.
• Los desarrolladores suelen tener problemas de diferencias entre entornos.
• No existe un estándar de intergación entre microservicios.

La madurez de tu ecosistema de microservicios mejora las capacidades operativas de todos los microservicios. Para ello, se inicia el proceso de adaptación de los microservicios a un servidor de contendores. La adaptación a este nivel de madurez requiere acciones:

• Los microservicios se incluyen dentro del ecosistema de los contenedores. Cada microservicio deberá estar en un contendor.  El típico "dockerizar una aplicación" o "dockerizar un servicio".
• Se establecen estándares globales referentes a los puntos con una afectación más operativa. Se trata de recomendaciones relacionadas con la infraestrcutura. Por ejemplo, los sistemas deben disponer de una implementación que permita la ejecución en múltiples instancias sin afectar a la consistencia del modelo de datos, deberán seguir volcar sus logs en un determinado filesystem, ... 

Esta acción mejora substancialmente la operativa puesto que el operador puede operar todos los sistemas de la misma manera y realizando acciones más amplias como el reinicio, parada, arranque, escalado de instancias a parte de la monitorización.

Este nivel conserva completamente la libertad del desarrollador con todos sus pros y contras y requiere unas adaptaciones mayoritariamente superficiales.

Puntos fuertes:

• Este tipo de ecosistema es el fuerte desacople que existe entre los microservicios.
• Permite utilizar soluciones completas (opensource y comerciales) como parte del ecosistema reduciendo substancialmente el time to market y el coste productivo.
• Baja complejidad operativa.
• Dependencias entre desarrollo y operaciones claramente definidas y resueltas en tiempo de desarrollo.

Puntos débiles:

• Complejidad evolutiva.
• Necesidad de disponer de gran variedad de skills en el desarrollo.
• Falta de estándares de integración.
• No existe un estándar de integración entre microservicios.
• Complejidad en el control de calidad de código estático y cobertura de tests unitarios.

Se crean y difunden recomendaciones de desarrollo a nivel global y se implementan patrones de diseño (como el event driven). Se crea lo que denominamos arquitectura de ecosistema mediante la cual se dota de los elementos comunes para ser usados entre los diferentes microservicios.

Los microservicios deben adaptarse a los nuevos patrones de diseño y deben implementarse teniendo en cuenta que están dentro de un ecosistema y no son sistemas independientes. Suelen ser adaptaciones ligeras, pero requieren de codificación, no se trata sólo de configuración.

Aunque se requieren algunas modificaciones de código, no hay restricciones en cuanto a lenguaje de programación de los microservicios.

Puntos fuertes:

• Los sistemas se pueden mantener por equipos completamente independientes.
• Permite utilizar soluciones completas opensource como parte del ecosistema reduciendo substancialmente el time to market y el coste productivo.
• Baja complejidad operativa.
• Visibilidad del negocio a nivel operativo.
• Dependencias entre desarrollo y operaciones claramente definidas y resueltas en tiempo de desarrollo.
• Patrones de integración claramente definidos.
• Una buena selección de los patrones de comunicación suele reducir la complejidad evolutiva.

Puntos débiles:

• Necesidad de disponer de gran variedad de skills en el desarrollo.
• Complejidad en el control de calidad de código estático y cobertura de tests unitarios.
• No permite aplicar modificaciones de arquitectura globales.

Una vez establecidas las reglas de convivencia entre los diferentes microservicios, pasamos a definir la microarquitectura de los microservicios. Aquí se establece el lenguaje de programación, se selecciona y configura el framework, se construyen las librerías de integración con el ecosistema y se seleccionan los patrones de diseño internos del microservicio.

Al disponer de un stack definido, nos permite automatizar el proceso de control de calidad (típicamente con sonarqube o similar) y construir microservicios mucho más uniformes. Esto mejora substancialmente la mantenibilidad del ecosistema.

Hay un punto importante que remarcar, que dispongamos de un ecosistema de microservicios restringido no significa que no podamos tener microservicios en diferentes lenguajes de programación. El tema es que para cada lenguaje que queramos añadir necesitaremos tener definida una microarquitectura. Aunque en teoría todo se puede, esto a la práctica limita bastante la selección de los lenguajes de programación puesto que añadir uno nuevo al ecosistema requiere una inversión en la creación de la microarquitectura.

Disponer de un set muy pequeño de microarquitecturas que estén correctamente definidas nos permitirá aplicar acciones globales en todos los microservicios y evitar la repetición de código. El desarrollo de cada microservicio podrá centrarse en el desarrollo de las funcionalidades del dominio. 

Puntos fuertes:

• Los ecosistemas se pueden mantener por equipos completamente independientes.
• Baja complejidad operativa.
• Más visibilidad del negocio a nivel operativo.
• Dependencias entre desarrollo y operaciones claramente definidas y resueltas mayoritariamente desde la microarquitectura.
• Patrones de integración claramente definidos.
• Complejidad evolutiva muy reducida.
• Equipo de desarrollo especializado en tecnología y con mayor flexibilidad funcional.
• Control de calidad de código estático y cobertura de tests unitarios muy estandarizada.
• Permite aplicar modificaciones de arquitectura globales.

Puntos débiles:

• Requiere el desarrollo a medida de todos los microservicios.

Es muy probable que existan ecosistemas en los que los microservicios estén en diferentes estados de madurez. Y que dichos microservicios puedan evolucionar de estado de madurez hasta un determinado nivel (porque la inversión que requiere la evolución del mismo no sea rentable). Por lo tanto es común encontrarnos con micro servicios en diferentes estados de madurez conviviendo en un mismo ecosistema.

El estado de la madurez del ecosistema dependerá de dos cosas, el primero es si disponemos de infraestructura, arquitectura y especificaciones necesarias para alcanzar dicho estado. El segundo es si los micro servicios han alcanzado dicho estado de madurez o no.