La palabra microservicios parece resonar bastante este último año y medio. Así que me puse a buscar y encontré una charla de Martin Fowler que aborda el tema y lanza algunas definiciones. Según él, las arquitecturas basadas en microservicios han estado presentes desde hace bastante tiempo pero es recién ahora cuando el concepto está tomando forma y se comienzan a adoptar explícitamente.

Las aplicaciones que utilizan microservicios están implementadas como un conjunto de pequeños servicios livianos y especializados que son implementados y desplegados de forma independiente. Lo opuesto a estas arquitecturas son las aplicaciones tradicionales, consideradas monolíticas porque implementan toda la funcionalidad en un único módulo de despliegue.

Características de las arquitecturas basadas en microservicios:

  • Usar los servicios como componentes: un componente es un módulo independiente de software que se puede reemplazar y actualizar, como las librerías (jars en Java, gems en Ruby). Las aplicaciones basadas en microservicios se caracterizan por estar compuestas por pequeños servicios web independientes que realizan tareas especializadas que resuelven una funcionalidad concreta del negocio.
  • Mayor libertad para la implementación: como los microservicios están completamente desacoplados entre sí, cada uno puede ser implementado con herramientas y lenguajes diferentes.
  • Equipos independientes y organizados en unidades de funcionalidad: a nivel interno de las organizaciones, el uso de microservicios tiene más que ver con la manera en que se organizan los equipos que con la arquitectura del software. La mejor manera de trabajar con microservicios es con la gente organizada en equipos autónomos y cada equipo es responsable de uno o varios microservicios. Es decir, cada microservicio tiene asignado un equipo estable de gente durante todo su tiempo de vida. Esta forma de organización agiliza mucho la comunicación interna y da estabilidad a las aplicaciones. El objetivo es que la organización de los equipos se refleje en la estructura de los servicios y las aplicaciones, como señala la famosa Ley de Conway: "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
  • Endpoints inteligentes: en algunas arquitecturas SOA se utilizan ESBs para rutear, coordinar, transformar y ordenar las invocaciones de los servicios web. En estas arquitecturas, los servicios (endpoints) suelen ser muy simples y las reglas de funcionamiento de las aplicaciones se configuran en el bus. Se crea así una dependencia con el ESB, que suele ser propietario. En las arquitecturas con microservicios no hay intermediarios y los servicios se comunican directamente entre si por su API (HTTP). Cada microservicio encapsula la lógica de su parte del negocio y expone un API de invocación. Es más simple.
  • Automatización: al aumentar la cantidad de módulos independientes, se hace necesario automatizar los procesos de despliegue, pruebas y distribución.
  • Diseñar para gestionar los fallos: las aplicaciones basadas en microservicios son por naturaleza más distribuidas que las monolíticas y es necesario contar con mecanismos de gestión de errores para mantener al sistema en funcionamiento cuando los microservicios fallan o no están disponibles.

Aunque está claro que los microservicios no son la respuesta a todos los males de la arquitectura de software, sí ofrecen soluciones a problemas recurrentes. Hay que evaluar bien cuándo aplicarlos. Preguntas que me quedan pendientes: ¿Son los microservicios parte de SOA? ¿O deben considerarse una especie diferente? El tiempo lo irá aclarando…