Microservicios

Una de las tendencias de diseño de las que se ha puesto de moda hablar recientemente son los microservicios. Para el que lo quiera entender de un plumazo, los microservicios son lo mismo que Service Oriented Architecture (SOA) pero cambiando los componentes Java Enterprise Edition (JEE) y los Enterprise Software Bus (ESB) por llamadas HTTP entre componentes escritos (posiblemente) en diferentes lenguajes y ejecutándose en diferentes máquinas.

Motivación para los microservicios

La motivación de negocio para los microservicios es que el patrón Modelo-Vista-Controlador (MVC) es insuficiente para dotar de las funcionalidades requeridas a una aplicación corporativa.

Ejemplos

Se puede desarrollar rápidamente una tienda online con tres capas: páginas web, back-end y base de datos, básicamente conectadas como una aplicación monolítica. Pero se necesitará, entre otras muchas cosas, comunicarse con los proveedores y transportistas. Una posibilidad es intercambiar ficheros de un lado para otro mediante FTP de toda la vida, lo cual sigue siendo muy válido para el intercambio de lotes, pero también habrá servicios de información y notificación en tiempo real que requerirán enlaces entre los servicios web de la tienda y los servicios web de los proveedores.

Otro ejemplo son las aplicaciones empresariales. Las empresas compran el ERP, el CRM y otros productos. Luego descubren que tienen que montar algún tipo de BPM porque los servicios que perciben los usuarios no se pueden prestar sólo con el software que maneja uno de los departamentos.

Arquitectura

Existe una teoría atribuida a Melvyn Conway en 1967 y ampliamente comprobada que afirma que el sistema que producirá una organización es isomorfo a la estructura de comunicación de las personas que lo desarrollaron. En las aplicaciones web y cliente servidor suele haber tres equipos: el de interfaz de usuario, el de middleware y el de bases de datos. Se dividen así por una cuestión de reparto de las competencias profesionales, pero desde el punto de vista del desarrollo de las funcionalidades que ve el usuario no existe ninguna razón por la cual haya que tener ingenieros de front, de back y y administradores de base de datos.

La arquitectura basada en microservicios propone que tanto el interfaz como las aplicaciones de usuario sean clientes de una colección de servicios que operan cada uno sobre un dominio.

Un gateway para los microservicios es necesario porque una página puede necesitar decenas de ellos y sería ineficiente realizar una llamada HTTP a cada microservicio desde el navegador. Además, el gateway puede lanzar en paralelo las peticiones a cada microservicio en lugar de ejecutar una única subrutina para obtener todos los datos necesarios para pintar una página web. Netflix utiliza este tipo de arquitectura basándose en RxJava (la presentación de Ben Christensen Functional Reactive Programminging the Netflix API contiene más detalles sobre esto).

Escalabilidad

Lo microservicios proponen escalar las aplicaciones mediante una especie de sharding de código y datos. Como dividir una aplicación en servcios no es una tarea para nada trivial.

Limitaciones

Los microservicios también tienen sus desventajas, y crean un conjunto nuevo de problemas, empezando por el despliegue. Úna aplicación monolítica se instala con un programa especializado o se despliegua como un archivo WAR en un contenedor de servlets. Pero los microservicios pueden estar distribuidos en diferentes servidores y estar escritos en diferentes lenguajes. El uso de herramientas de generación de máquinas virtuales como Vagrant y de despliegue continuo como Jenkins es una necesidad imperiosa en las arquitecturas microservicios.

Los microservicios tampoco solucionan el problema del versionado. Lo que proponen es hacer resilientes los clientes a fallos en los microservicios proveedores, lo cual es más fácil de decir que de hacer.

Pero quizá el problema más grave es el mantenimiento de la consistencia de datos replicados entre los dominios de diferentes servicios. En la mayoría de las arquitecturas basadas en microservicios los datos son sólo eventualmente consistentes, lo que significa que es posible que dos clientes que se ejecutan en paralelo reciban resultados diferentes. El mayor error de diseño que yo he encontrado hasta ahora en las aplicaciones basadas en servicios es montar la replicación de forma explícita y carecer de un buen mecanismo de consolidación de datos. Conviene recordar que evitar la redundancia y la inconsistencia de datos fueron las dos razones principales para diseñar en un principio aplicaciones monolíticas transaccionales.

Migración

Pero ¿qué hacer si ya se tiene una aplicación monolítica que se está quedando pequeña y se desea incorporar microservicios? Bien, yo no recomendaría en absoluto tirar a la basura la aplicación monolítica sino crear «código pegamento» para hacer que los servicios utilicen funcionalidades del monolito.

Otra cuestión de debate es cuándo debería una arquitectura basada en microservicios incorporarse al desarrollo. Algunos argüyen que es mejor que una start-up empiece con una aplicación MVC monolítica convencional para lanzar el mínimo producto viable lo antes posible y no demorarse en la construcción de una arquitectura de servicios distribuidos al principio. Yo, personalmente, creo que es un error sacar a producción una aplicación cuya arquitectura se sabe desde el principio que es inadecuada a los objetivos de negocio de la empresa. Además una arquitectura basada en microservicios no es intrínsecamente más costosa de desarrollar que un monolito, sólo requiere un conjunto de competencias diferente que algunos desarrolladores no tienen.

Más información:
Migrating to Microservices (Adrian Cockcroft)
Microservices – A Reality Check(point) (Andrew Harmel-Law)
¿Qué es eso de los microservicios? (Ana M. del Carmen García Oterino)
The Seven Deadly Sins of Microservices (Daniel Bryant)