¿Qué es la arquitectura de microservicios?

Como ya sabréis los habituales de este blog, nos encanta probar las últimas tendencias tecnológicas, y más si estas sirven para acercar los planteamientos y las necesidades de las TI y las de la propia empresa.

El que os traemos hoy es uno de los mejores ejemplos y ha ganado popularidad rápidamente en los últimos años: la arquitectura de microservicios. Se trata de una manera de estructurar el desarrollo de una aplicación (y por aplicación me refiero a un software que tiene una tarea específica, de cualquier tipo, no tiene por qué ser una app móvil como cabría pensar) en pequeñas porciones en torno a la los procesos de negocio que tratan.

Es posible que se encuentren referencias a los microservicios como una forma de Arquitectura Orientada a Servicios (SOA), o incluso que se usen como sinónimos, pero las experiencias  previas a los microservicios, normalmente no muy positivas, hace necesario que se diferencien. Lo más aceptado es que mientras que los SOA, tendencia en los años 2000, requerían de un cierto acoplamiento débil entre los diferentes servicios, en los microservicios, tendencia en los 2010, están totalmente desacoplados entre ellos.
 

Software monolítico vs Microservicios

 
Probablemente se entienda mejor qué es un microservicio explicando cuál es la estructura opuesta y más tradicional: el software monolítico.

La estructura de una aplicación monolítica, después de separar o no la interfaz de usuario final, consistía en que toda la lógica de negocio corría en un bloque de software que se encargaba de gestionar todos los procesos requeridos. Esto implica varias cosas, como que todo el bloque debe realizarse sobre la misma tecnología, se ejecuta sobre un mismo proceso y, especialmente, cualquier modificación que se realice supone necesariamente desplegar una nueva versión del software al completo, realizar las pertinentes pruebas funcionamiento, compatiblidad, etc.

Volviendo al omnipresente ejemplo del comercio electrónico, el backend lo gestiona todo: la creación de usuarios, el catalogo de productos, el proceso de pago, la gestión de envíos y devoluciones, la administración, etc.

Por su parte, los microservicios dividen todos estos procesos en mini-aplicaciones con la misma estructura de los procesos del propio negocio, se encargan de ellos de manera independiente y autónoma y, de ser necesario, se comunican entre sí a través de una API o interfaz de programación de aplicaciones. Esto hace que el desarrollo sea mucho más sencillo, ya que se pueden ir añadiendo microservicios según se requiera, y la modificación de la lógica interna de cada uno de ellos es independiente de todos los demás, facilitando sus pasos a producción, actualizaciones, aislamiento de errores, etc.
 

La Ley de Conway

 
Organizar el software en torno a los procesos de la empresa puede ser mucho más beneficioso de lo que pueda parecer, y así lo enuncia la Ley de Conway. Realmente, se trata casi más de un refrán que de una ley como tal, que fue formulada en 1967 por el informático Melvin Conway de la siguiente manera: “Cualquier organización que diseñe un sistema reproducirá un diseño cuya estructura copia el sistema de comunicación de la empresa”.

En resumidas cuentas, pese a que inicialmente se pueda realizar una estructuración tecnológica, el componente humano, tenderá a replicar su propia comunicación entre personas o entre departamentos en el software, e ir en contra de esto, suele acarrear problemas internos. Y esta misma filosofía es la que pretende fomentar los microservicios, además de entre ellos, entre los grupos de trabajo que los desarrollen, reduciendo fricciones improductivas.

Otra de las grandes ventajas de los microservicios, especialmente en entornos muy grandes, pero no sólo en estos, es que como cada proceso que forma parte de la aplicación se desarrolla de manera independiente y corre en su propio proceso, se puede desarrollar sobre la tecnología, estructura e incluso, paradigma, que más le convenga según su naturaleza. Si miramos, por ejemplo, hacia el almacenamiento de datos, cada microservicio puede utilizar un sistema de base de datos diferente, o incluso no utilizar ninguno. Es habitual que para datos de alta frecuencia de acceso pero poco volumen se utilicen bases de datos en memoria como Redis, mientras que datos muy voluminosos a los que se accede de manera esporádica es conveniente utilizar un sistema de base de datos tradicional, en disco, tipo SQL o similares. Pero va más allá, porque cada microservicio puede ser desarrollado, incluso en paralelo, por un grupo de trabajo diferente que, quizá, pueda necesitar de unas habilidades concretas o unos conocimientos del propio negocio específicos. En estos casos, se encuentra un ahorro de tiempo y costes en desarrollo muy considerable.
 

¿Orquestación o coreografía?

 
Obviamente, un cambio de estructura de esta magnitud también añade sus propias necesidades, como es la de la correcta cooperación entre los diferentes microservcios, ya que si bien la comunicación entre ellos puede estar bien definida, al crecer la complejidad de la solución, también suele crecer la necesidad de organizar cómo interactúan. Aquí aparecen dos formas de coordinar sus tareas: orquestación o coreografía. Los nombres de por sí son bastante esclarecedores sobre su funcionamiento.

La orquestación es poco recomendable, ya que requiere de un mecanismo que se encargue de distribuir peticiones y enviar datos a un servicio cuando otro ya haya acabado su trabajo, como si se tratara de un director de orquesta.

La coreografía es la aproximación recomendada para microservicios, donde cada componente conoce perfectamente su función, sabe en qué momento debe actuar y a dónde enviar sus datos al terminar. Es decir, cada microservicio es autónomo y no necesita de una directriz externa.
 

Los grandes de Internet reconvertidos a microservicios

 
Encontramos numerosos ejemplos de implementación real entre los grandes de la industria que, debido a su tamaño, han encontrado que “refactorizar” su bloque monolítico en microservicios era la mejor opción, como Amazon, Netflix, Twitter o Ebay.

Un buen ejemplo es Uber, que ha escrito varias entradas de su blog sobre ingeniería acerca de este tema y cómo llevar a cabo este proceso les ha dado la oportunidad de adoptar nuevas tecnologías. Incluso, destacan que en una organización tan grande y con un crecimiento tan rápido es muy difícil estar al tanto de todos los cambios y nuevas funcionalidades que se están desarrollando, por lo que era habitual que se duplicaran trabajos en diferentes puntos de la organización. Pero, la estructura en microservicios, les ha ayudado a implementar un sistema que trata de evitar esta problemática mediante peticiones de autorización, donde cada responsable de microservicio debe solicitar y recibir aprobación de un órgano de gestión superior antes de iniciar los trabajos en una nueva funcionalidad.

Parece que las nuevas tendencias tecnológicas pretenden optimizarse replicando el comportamiento humano, y una filosofía casi tan antigua como la propia humanidad no podría encajar mejor en este momento: “Divide y vencerás”.
 

Contacta ahora con Sarenet