-Arquitectura de Microservicios-

Desde que lo escuché por primera vez, hace más o menos dos años, este término empezó sonar cada vez más a menudo. Realmente lleva más tiempo, al menos desde unos años antes, definiendo un estilo arquitectónico que James Lewis y Martin Fowler describieron como un conjunto de pequeños servicios que se comunican entre si, normalmente, a través de HTTP.

No obstante, no cualquier arquitectura orientada a servicios construye microservicios. En esta entrada trataré de resumir algunas características que dieron origen al término y lo hicieron tan atractivo, y con las que muchos desarrolladores nos hemos encontrado estos últimos años.

-Características comunes-

Como dice el artículo de Lewis y Fowler, no existe una definición formal, pero sí algunas características comunes que esperaríamos encontrar en estas arquitecturas. En mi opinión, éstas serían las más importantes:

• Componentes como servicios

Una arquitectura de microservicios tratará de reflejar los componentes como servicios siempre que sea posible, ya que de ese modo pueden ser desplegados de forma independiente, facilitando el mantenimiento, la escalabilidad y reduciendo el acoplamiento.

• Organización en torno a áreas del negocio

La aplicación se dividirá en servicios en torno a áreas del negocio (pedidos, logística, facturación…) que requerirá equipos multifuncionales, en lugar de en torno a la tecnología (interfaz de usuario, lógica de negocio y base de datos), que suele responder a la Ley de Conway, y propicia la aparición de lógica en todas partes.

• Endpoints inteligentes y tuberías tontas

La arquitectura de microservicios favorece este enfoque frente al desarrollo de mecanismos de comunicación sofisticados, como los ESB, que a menudo incluyen lógicas complejas para el enrutamiento de mensajes, la transformación e incluso la aplicación de reglas de negocio.

• Automatización de la infraestructura

Algunas de las características citadas como la facilidad del mantenimiento, la escalabilidad y los equipos multifuncionales, se complementan con técnicas de automatización de pruebas, de integración y entrega continua y de implementación de nuevos entornos, que se aplican de forma más sencilla en estos pequeños servicios.

• Diseño emergente

La implementación de componentes como servicios nos da más flexibilidad en las entregas, algo que debe ser aprovechado para facilitar el cambio y lograr un diseño emergente.

Por otro lado, como bien apunta Ana M. Del Carmen en el blog de Javier Garzás, hay pros y contras, y los microservicios introducen complejidad a la solución. Podéis repasar algunos retos y consejos en su artículo: ¿Qué es eso de los microservicios?

-Algo más que muchos servicios-

Se podría decir que esto no son más que servicios con una granularidad muy fina, o que surgen como una arquitectura SOA bien hecha. Sam Newman lo describe es su libro como una tendencia que ha surgido de forma natural:

Diseño guiado por el dominio. Entrega continua. Virtualización bajo demanda. Automatización de la infraestructura. Pequeños equipos autónomos. Sistemas a escala. Los microservicios han surgido en este mundo. No se inventaron ni se describieron antes de utilizarse; surgieron como una tendencia, o un patrón, a partir de su uso en el mundo real. Sin embargo, solo existen gracias a lo que ha ocurrido anteriormente. Sam Newman (2015). Building Microservices.

Desde luego esto es algo más que muchos servicios, como dice Newman, los microservicios son un estilo arquitectónico que surge a partir de varias técnicas que han dado buenos resultados en el mundo del desarrollo. Este estilo, además, propicia el uso y la mejora de estas técnicas. La unión perfecta.