Microservicios: más que la suma de sus partes

El software se puede desarrollar de diversas maneras. En lugar de realizar un proyecto como un todo global, en ocasiones puede ser más pertinente distribuir las tareas en pequeños componentes, como los llamados microservicios o microservices. Este término no solo tiene que ver con la programación de una aplicación informática, sino que también desempeña un papel significativo en la planificación con el fin de agilizar la gestión del proyecto. ¿Cuáles son las ventajas de la arquitectura de microservicios, cómo funciona y qué proyectos confían ya en ella?

No está acotado claramente cuándo se puede hablar de una arquitectura basada en microservicios y cuándo de otra que no lo está. A esta confusión se añade que los microservicios no hacen solo referencia a la tecnología de desarrollo de software, sino también, y en gran medida, a una forma de trabajar de los propios programadores. ¿Cuál es la mejor forma de llevar a la práctica grandes proyectos de programación? Como regla general, puede recordarse que los proyectos que implementan microservicios siempre siguen la filosofía Unix de Ken Thompson: “Do one thing and do it well” o, lo que es lo mismo, haz una cosa y hazla bien. Se trataría entonces de concentrarse en una sola tarea y llevarla a la perfección. Esta máxima no constituye únicamente una recomendación para el trabajo de los programadores, sino que también describe la forma de funcionar de cada microservicio.

En términos de desarrollo de programas, se forman pequeños equipos, cada uno de los cuales se ocuparía de un solo servicio realizado en un microservicio. En lo que respecta a la gestión de proyectos, se trata de definir en qué se concentra cada equipo y su independencia. En lugar de supeditarse a una administración central, cada equipo es responsable de su propio producto final en cada fase de su ciclo de vida, desde la creación a la entrega y a la consiguiente monitorización. Resultando en una arquitectura de software modular, esta forma de trabajar conlleva numerosas ventajas.

Una arquitectura basada en microservicios consiste principalmente en una evolución de la arquitectura orientada a servicios o SOA (Service-oriented architecture), modelo en el cual también desempeñan un papel los servicios de poco tamaño. Estos, sin embargo, siguen estando integrados en un sistema mayor y no son tan autónomos como se espera de una arquitectura de microservicios. Del mismo modo que no hay una definición clara para este término, también SOA es algo ambiguo, lo que provoca que fluyan transferencias entre un modelo y otro.

La programación tradicional funciona según el principio del monolito, implementando todas las tareas en una gran aplicación. En ella, cada uno de los servicios recurre a una misma base de datos y se entrega por medio de una interfaz de usuario, todo en una única aplicación. El enfoque de microservicios parte de la idea de los módulos, es decir, que cada microservicio es responsable de una única tarea. Tan diferentes como los resultados son los métodos de trabajo de ambas visiones.

Mientras en una arquitectura de microservicios cada equipo se ocupa del desarrollo de un microservicio, en el desarrollo con enfoque monolítico los equipos se organizan de forma diferente en función de la tecnología que utilizan: mientas uno se dedica a las bases de datos, otro se ocupa de programar los diversos servicios y otro se encarga de diseñar la interfaz de usuario. Otros grupos de trabajo son responsables de publicar actualizaciones, del mantenimiento y de la monitorización. En el desarrollo de un monolito todos los equipos dependen unos de otros. En una arquitectura de microservicios, en cambio, el objetivo es evitar la interdependencia en lo posible.

En una arquitectura de microservicios una aplicación se realiza a partir de pequeños módulos monofuncionales, los llamados microservicios. Estos componentes se desarrollan de forma aislada conformando entre todos el producto final. Esta arquitectura conlleva algunas ventajas:

En el desarrollo de un microservice, los equipos trabajan de forma autónoma sin una instancia superior que indique el procedimiento a seguir, ni la necesidad de coordinarse con el resto de equipos en todo momento. La atención del equipo se centra en la tarea, en la utilidad del microservicio. La ventaja de este método de trabajo es que es el equipo de desarrolladores el que escoge la vía más adecuada al microservicio en que trabajan y no la que otros han pensado. Esto es así hasta el punto de que es posible incluso utilizar lenguajes de programación diferentes para diversos microservicios o implementar bases de datos o sistemas para gestionarlas de producción propia. Esto es posible porque cada microservicio posee su propio entorno de ejecución.

Como resultado de la independencia, el sistema se hace más robusto. Si un microservicio falla, no se ve afectada la aplicación entera, sino solo un aspecto y, como se trata de un proceso de tamaño razonable, el error se puede encontrar fácilmente. En lugar de explorar el farragoso código fuente de un gran monolito solo es necesario analizar un programa relativamente pequeño.

En este contexto puede hablarse también de entrega continua (continuous delivery), metodología por la cual algunos productos de software se mantienen en constante desarrollo. Los microservicios permiten a los fabricantes no tener que planificar y gestionar grandes ciclos de actualizaciones, porque los cambios introducidos en los microservicios se van publicando directamente, siempre tras una fase de prueba, sin depender del resto de procesos. Los más pequeños cambios en un monolito de despliegue, en cambio, implican ya un gran esfuerzo. Modificar un microservicio que solo cumple con una tarea es mucho más fácil, pues al fin y al cabo consume muchos menos recursos.

Esta agilidad también beneficia a la entrega continua, puesto que el equipo encargado de un microservicio está especializado y puede llevar a cabo los cambios sin grandes dificultades. Además, solo se admite un cambio por versión en el código fuente, sea una característica nueva o la reparación de un error, lo que contribuye también a la rapidez en la introducción de modificaciones y, con ello, a asegurar la estabilidad del sistema completo a largo plazo.

Al final todos los componentes se encajan y a pesar de lo diferente que pueda ser la estructura de cada microservicio, ha de contener puntos de conexión comunes. Estos deberían estar diseñados de la forma más simple posible para que la conexión tenga poco impacto en el proceso en sí. Por este motivo, la mayoría de desarrolladores confían en APIS REST. Por medio de los coherentes y ligeros métodos HTTP, como GET o POST, cada microservicio puede comunicarse fácilmente con los demás e intercambiar la información que necesitan.

Cuando se debe escalar hacia arriba un monolito, esto es, un sistema cerrado que agrupa en sí todos los procesos, no queda más remedio que escalar el sistema completo. La arquitectura de microservicios, en cambio, permite a los desarrolladores escalar con un grado de detalle excelente. Solo es necesario fortalecer el servicio que lo requiere, lo que contribuye a que el producto final sea mucho más ligero y parco en recursos. Del mismo modo, integrar un servicio completamente nuevo en el sistema no requiere tanto trabajo.

Los microservicios se mantienen aislados los unos de los otros y se ejecutan en su propio entorno. Solo se comunican entre sí a través de interfaces. Con objeto de conseguir este aislamiento puede recurrirse a diferentes opciones:

• Contenedores: la forma quizá más común de desarrollar una arquitectura de microservicios es la basada en contenedores. Estos representan un método muy ligero de virtualización, puesto que no se crean máquinas virtuales completas, sino que se parte de un mismo sistema operativo y se utiliza su núcleo o kernel. En los contenedores, los microservicios son completamente autónomos, pues todo lo que necesitan para funcionar está ya contenido en ellos.
   
• Máquinas virtuales: es posible crear una máquina virtual para cada microservicio. También en este caso cada uno de ellos puede funcionar de forma aislada del resto. El problema de este formato frente a una tecnología de contenedores como Docker es que cada máquina necesita su propio sistema operativo y con él muchos recursos.

Otra opción sería instalar una instancia-servidor física propia para cada microservicio. En la práctica, sin embargo, esto resultaría en un derroche de recursos, motivo por el cual suele optarse por la virtualización. Con todo, lo más importante, sea cual sea la elección, es que se dé un aislamiento real. No se recomienda ni ejecutar varios microservicios en un único servidor ni todos juntos en un contenedor. Esto podría provocar conflictos entre las diversas aplicaciones.

Para evitar sobrecargas en el sistema se utilizan balanceadores de carga, que reparten la carga automáticamente entre las diferentes instancias para evitar fallos.

La arquitectura de microservicios ya ha entrado en los sistemas de grandes empresas que de esta forma han logrado resolver ciertos problemas u optimizar sus procesos. Los ejemplos de Netflix, Spotify o eBay muestran por qué las grandes compañías, con sistemas monolíticos consolidados, se deciden por desmontar su arquitectura y cambiarla por los microservicios. Compañías informáticas como Google o Amazon también trabajan así, habiendo integrado en parte sistemas modulares cuando aún no habían recibido un nombre.

En el pasado, cuando todavía no era un servicio de streaming, sino que enviaba por correo películas en formato DVD, Netflix se basaba, como la mayoría de empresas, en un sistema monolítico, hasta que en 2008 un error en una base de datos provocó una interrupción del servicio durante cuatro días. A partir de este momento se decidió desintegrar el antiguo sistema y dividirlo en microservicios. Con esto se logró que la empresa pudiera lanzar los cambios mucho más rápidamente y que las reparaciones también pudieran llevarse a cabo con mucha más agilidad. Como el sistema de Netflix es muy extenso, la empresa desarrolló un programa propio para coordinar los diferentes microservicios entre sí: este se conoce como Conductor.

Conductor permite que Netflix pueda gestionar los microservicios de forma central (pausar o reiniciar) o escalarlos. En el núcleo del programa trabaja un servicio de nombre Decider que puede planificar los procesos de forma automatizada y reaccionar a eventos en el workflow. Otros programas desarrollados por Netflix para trabajar eficazmente con microservicios son Mantis (Stream processing), Dynomite (datastore) y Vizceral (traffic intuition).

Spotify, otro popular servicio de streaming, también apuesta por los microservicios. El mayor desafío al que la empresa debe hacer frente a diario es la enorme competencia: con Amazon, Apple y Google, el mercado del streaming de audio tiene a algunas de las empresas informáticas más poderosas del mundo como compañeros de equipo. Al mismo tiempo, los desarrolladores, debido al incremento sostenido de suscriptores, han de cubrir una demanda en constante crecimiento y observar ciertas reglas propias del negocio, como los derechos de licencia. Para poder responder con rapidez a las innovaciones de la competencia y publicar las suyas propias aún más rápido, los microservicios constituyen la solución adecuada para Spotify. La función por la cual los usuarios obtienen posibles resultados cuando teclean un término en su buscador, por ejemplo, es un microservicio cerrado en sí que tiene a su propio equipo responsable.

Spotify también saca provecho de la consistencia propia de la arquitectura de microservicios: cuando un microservicio falla, el producto completo no se ve afectado. En total pueden contarse más de 800 microservicios activos en Spotify. Para una gran parte de ellos, la empresa utiliza Java, y no porque no puedan escribirse en lenguajes diferentes, sino por mantener el flujo de trabajo: como los programadores cambian constantemente de equipo, el trabajo es más viable si todos utilizan el mismo lenguaje.

La plataforma de ventas eBay comenzó, como la mayoría de sistemas, como uno monolítico, pero con el tiempo acumuló 3,4 millones de líneas de código en un único archivo. Esto llevó a la empresa a plantearse romper el monolito y desarrollar microservicios en Java. Aquí los diversos servicios también se comunican con el resto por REST.

El hecho de que tanto eBay como muchas otras empresas se hayan decidido a abandonar el enfoque monolítico por la arquitectura de microservicios y lo hayan logrado con éxito demuestra los beneficios de este moderno procedimiento. Si en los primeros días de un proyecto online con pocos usuarios activos y una oferta modesta una aplicación monolítica es suficiente, a medida que se van incrementando los requerimientos, el sistema se convierte en un ente torpe y estático que dificulta el crecimiento.

Aun siendo muchos los factores que hablan a favor del desarrollo de sistemas basados en microservicios, este método no tiene que ser la mejor solución para cualquier empresa o proyecto. Especialmente para programas informáticos sencillos que han de solucionar pocas tareas, la utilización de microservicios puede conllevar un esfuerzo comparablemente mayor porque, además de la creación de los servicios, su mantenimiento, su desarrollo posterior y su monitorización también significan mucho trabajo. Precisamente es durante el control de los procesos cuando se ha de sopesar de la forma más exacta posible si los microservicios lo favorecen o lo perjudican, ya que si bien son muy fáciles de analizar y medir, si crece demasiado su número esta tarea se vuelve titánica.

Echando un vistazo a las ventajas de este método de trabajo se ve claro que no conviene a cualquier proyecto, por lo menos a corto plazo. Un punto fuerte del trabajo con microservicios es la autonomía de los distintos equipos, que tiene el objetivo de evitar, por ejemplo, que un equipo tenga que esperar a los resultados de otro. Sin embargo, cuando el equipo entero solo se compone de unas pocas personas, tal separación pierde su sentido. Además, y siguiendo la ley de Conway, un equipo pequeño que en la práctica no necesita divisiones y todo se soluciona en común persigue un fin distinto.

También en los grandes equipos la introducción de este enfoque requiere un cambio profundo. Los puestos que dirigen el desarrollo suelen desaparecer, porque los equipos se organizan a sí mismos. Una reestructuración así requiere una inversión de tiempo y costes, un factor que no debe dejarse de lado en caso de llevarla a cabo.

Algunos partidarios de las arquitecturas de microservicios recomiendan en consecuencia una estrategia Monolith first. Según esta, al comienzo conviene iniciar un proyecto como monolito y agotar las ventajas de esta concepción sobre todo en los primeros días. Solo cuando el proyecto ya ha adquirido una envergadura suficiente debería cambiarse a una arquitectura de microservicios. Entre ambos sistemas se encuentra la arquitectura orientada a servicios o SOA, adecuada como paso intermedio y con la cual también se procede con módulos. Aquí, cada uno de los servicios representa procesos de negocio.