Microservicios: Lo que se debe tener claro

 

José Luis Juárez Manzano – Security Architect de Víntegris

José Luis Juárez Manzano – Security Architect de Víntegris

Es casi imposible moverse por los círculos DevOps sin escuchar la palabra Microservicios mencionada una y otra vez en todos lados.

He asistido a un montón de discursos y conferencias sobre el tema y sólo recientemente he dado con una explicación lo suficientemente práctica, que me permitió alejarme del diseño de arquitecturas clásico, aclarando algo más el campo de visión necesario para tomar decisiones.

¿Qué son microservicios?

Microservicios son lo opuesto a las aplicaciones monolíticas. Hasta el momento esto es algo muy obvio. ¿Pero qué significa esto? ¿Aplicaciones de aspecto agradable y limpio, que se comportan muy bien en diagramas de arquitectura y donde la complejidad se esconde en el cuadro más oscuro y menos detallado? Es justo lo contrario. He visto y desarrollado lo suficiente para multitud de plataformas y lenguajes, como para aseguraros que esta simplicidad percibida sólo oculta la complejidad real existente y además muchos problemas sin resolver. Los microservicios hacen que la complejidad sea más visible, tangible y por lo tanto más manejable. Hace tiempo escuché una frase que se me quedó grabada a fuego y no he podido olvidar: “Los microservicios no son nada más que la parte buena de SOA, pero además implementada correctamente”. Dentro de esta frase se encuentra la mayor parte de la definición de un buen microservicio, que no es más que un servicio (aplicación) creado para un propósito, que además es autónomo e independiente, y tiene una interfaz claramente definida y persistencia aislada (incluso hasta el punto de tener una base de datos propia).

¿Cuáles son los beneficios de los microservicios?

Con el tiempo, todos hemos aprendido que no hay una “arquitectura en su estado final”. Una arquitectura y sus sistemas siempre evolucionan y tan pronto como se termina la implementación de la versión 1.0, ya se está preparando el próximo cambio para la siguiente versión. En el pasado, los cambios de una arquitectura eran bastante difíciles de conseguir, ya que había que reemplazar sistemas grandes y sobredimensionados, además de pelear con los equipos involucrados y la burocracia de cada uno de ellos. Con los microservicios, se crea un ecosistema de arquitectura que nos permite cambiar componentes pequeños en cualquier momento y evitar las migraciones en modo big bang. Esta flexibilidad significa que seremos mucho más rápidos en la evolución de nuestra arquitectura. Además, una estructura de microservicios implica que los equipos tienen un mayor nivel de control sobre su servicio y esta propiedad es probable que obligue incluso a que los equipos sean más productivos y responsables mientras desarrollan cada artefacto. El proceso de implementación y de liberación se convierte en algo mucho más sencillo, ya que no tienes que preocuparte de las dependencias que deban cumplirse en la liberación y el despliegue de los servicios. Esto, por supuesto, viene acompañado de una mayor complejidad en las pruebas de los servicios, ya que el número de permutaciones posibles a tratar aumenta considerablemente, por lo que la automatización y las estrategias de ensayo automáticas son muy importantes.

Por supuesto, estamos asumiendo como cierto que las infraestructuras utilizadas también deben cambiarse, para albergar dichos microservicios y posibilitar su comunicación e interacción con rendimientos adecuados en todo momento y situación.

¿Cuándo hay que usar microservicios?

Yo creo que los microservicios son útiles en las áreas en las que una empresa invertirá en tiempo. Me explico: el arquitecto siempre deberá fijarse en las áreas donde la velocidad de comercialización de un producto es especialmente importante; esto es así porque la velocidad es una de las principales ventajas de los microservicios.

Aquí es donde la maraña de las dependencias de una arquitectura monolítica presenta sus deficiencias.

Temas como la interacción entre librerías de código, tiempos asíncronos de despliegue de artefactos, procesos de promoción entre diferentes entornos, etc. pueden ocasionar que algún componente retrase el ciclo de liberación y por tanto causar retrasos en la comercialización del producto.

Otra área en la que se pueden aplicar los microservicios, es donde no se pueden escalar de forma vertical por mucho más tiempo de manera económica.

Las capacidades de escalamiento horizontal de los microservicios son propias de este tipo de servicios, lo que aumenta las posibilidades de encontrar modelos de escalado más económicos. Por supuesto, un movimiento hacia microservicios requiere de una inversión importante en diferentes aspectos, por lo que siempre tendremos que migrar el área que antes nos proporcione retorno de inversión.

¿Qué se necesita para tener éxito con los microservicios?

Creo que esto no le va a sorprender a nadie, pero he de comentarlo igualmente. El nivel de complejidad adicional que viene con los servicios desplegables de forma independiente, que a su vez podrían existir en producción en múltiples versiones, significa que se necesita conocer de forma muy detallada y completa todo lo que implica. Y con esto quiero decir que se necesita estar curtido en prácticas de ingeniería y arquitectura, tener un proceso de despliegue bien engrasado y con “todo automatizado” (integración continua, despliegue, testing, etc). De lo contrario, el esfuerzo y la complejidad para tratar de mantener esto manualmente de forma rápida, terminará aplastando a todo el equipo y parte de la empresa, ya que el peso de todo esto será mayor que los beneficios que nos puedan aportar. La Ley de Conway dice: “los sistemas se parecen a la estructura organizativa en que se construyeron”. Por tanto, para construir una arquitectura con microservicios, tenemos que dominar el principio “Agile y DevOps”, lo que implica disponer de equipos multifuncionales, arquitectos con visión cristalina y completa de los requisitos de negocio. De hecho, lo ideal es que además se alineen con las áreas de negocio, ya que serán sus Product Owner y deberán comprenderse al 100%. Estos equipos tienen la plena propiedad de los microservicios que crean desde que nacen y hasta que mueren. Esto tiene sentido si los servicios son pequeños y auto-contenidos; es como tener múltiples equipos (DBAs, desarrolladores .NET, etc.) que participan en un mismo fin. En caso contrario estaremos agregando una sobrecarga a los servicios y por tanto al equipo que los construye. Mi opinión es que los microservicios son el siguiente paso de madurez de aplicar “DevOps”, “Agile” y otras metodologías, ya que requieren que las organizaciones y las personas pongan en práctica su experiencia, profesionalidad y compromiso con el equipo que trabajan.

¿Cómo se puede empezar?

Antes de continuar he de decir que voy a asumir como cierto que estás utilizando metodologías “Agile” y que entiendes el concepto “DevOps”. Éste es un requisito previo e imprescindible para la adopción de microservicios. Ahora bien, si tu organización está dispuesta a seguir adelante,  elegir un piloto y crear un microservicio, que por supuesto se adhiere a la definición anterior y dispone valor empresarial real (por ejemplo, algo que está siendo muy utilizado, está orientado al cliente y está en una pila de tecnología adecuada), he de comunicarte que es muy probable que el primero no llegue a ser un gran éxito, pero seguro que aprenderéis de la experiencia y en el siguiente intento triunfáis. Los microservicios requieren una inversión de la organización, en el personal y por supuesto un cambio casi radical de mentalidad, ya que al principio el valor del objetivo inicial podría no estar claro. Por ejemplo: podemos creer que resulte más barato añadir la funcionalidad a nuestra actual arquitectura monolítica, pero si comparamos el “ROI” de ésta con el equivalente en una arquitectura de microservicios, a largo plazo la flexibilidad, la velocidad y la capacidad de recuperación será diametralmente opuesta, dando ventaja a los microservicios a pesar del esfuerzo que ello implique.

¿Crees que vas a terminar con una arquitectura de microservicios pura? Te puedo asegurar que muy probablemente no lo consigas. Esto es así porque tus servicios básicos sólo podrían migrar a una arquitectura que esté construida y diseñada para evolucionar, por lo que a menos que te lo tomes en serio y construyas desde cero, todo quedará en un costoso intento de volar. Un buen aliciente es pensar que con los microservicios podrás darle una mejor calidad y valor añadido a tu cliente en un mercado en constante cambio y, como contrapartida, obtendrás mayores beneficios con menor esfuerzo.

 

 

Por José Luis Juárez Manzano – Security Architect de Víntegris