Mi­cro­se­r­vi­cios: más que la suma de sus partes

El software se puede de­sa­rro­llar de diversas maneras. En lugar de realizar un proyecto como un todo global, en ocasiones puede ser más pe­r­ti­ne­n­te di­s­tri­buir las tareas en pequeños co­m­po­ne­n­tes, como los llamados mi­cro­se­r­vi­cios o mi­cro­se­r­vi­ces. Este término no solo tiene que ver con la pro­gra­ma­ción de una apli­ca­ción in­fo­r­má­ti­ca, sino que también desempeña un papel si­g­ni­fi­ca­ti­vo en la pla­ni­fi­ca­ción con el fin de agilizar la gestión del proyecto. ¿Cuáles son las ventajas de la ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios, cómo funciona y qué proyectos confían ya en ella?

No está acotado cla­ra­me­n­te cuándo se puede hablar de una ar­qui­te­c­tu­ra basada en mi­cro­se­r­vi­cios y cuándo de otra que no lo está. A esta confusión se añade que los mi­cro­se­r­vi­cios no hacen solo re­fe­re­n­cia a la te­c­no­lo­gía de de­sa­rro­llo de software, sino también, y en gran medida, a una forma de trabajar de los propios pro­gra­ma­do­res. ¿Cuál es la mejor forma de llevar a la práctica grandes proyectos de pro­gra­ma­ción? Como regla general, puede re­co­r­dar­se que los proyectos que im­ple­me­n­tan mi­cro­se­r­vi­cios 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 co­n­ce­n­trar­se en una sola tarea y llevarla a la pe­r­fe­c­ción. Esta máxima no co­n­s­ti­tu­ye úni­ca­me­n­te una re­co­me­n­da­ción para el trabajo de los pro­gra­ma­do­res, sino que también describe la forma de funcionar de cada mi­cro­se­r­vi­cio.

En términos de de­sa­rro­llo de programas, se forman pequeños equipos, cada uno de los cuales se ocuparía de un solo servicio realizado en un mi­cro­se­r­vi­cio. En lo que respecta a la gestión de proyectos, se trata de definir en qué se concentra cada equipo y su in­de­pe­n­de­n­cia. En lugar de su­pe­di­tar­se a una ad­mi­ni­s­tra­ción central, cada equipo es re­s­po­n­sa­ble de su propio producto final en cada fase de su ciclo de vida, desde la creación a la entrega y a la co­n­si­guie­n­te mo­ni­to­ri­za­ción. Re­su­l­ta­n­do en una ar­qui­te­c­tu­ra de software modular, esta forma de trabajar conlleva numerosas ventajas.

Una ar­qui­te­c­tu­ra basada en mi­cro­se­r­vi­cios consiste pri­n­ci­pa­l­me­n­te en una evolución de la ar­qui­te­c­tu­ra orientada a servicios o SOA (Service-oriented ar­chi­te­c­tu­re), modelo en el cual también de­sem­pe­ñan un papel los servicios de poco tamaño. Estos, sin embargo, siguen estando in­te­gra­dos en un sistema mayor y no son tan autónomos como se espera de una ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios. Del mismo modo que no hay una de­fi­ni­ción clara para este término, también SOA es algo ambiguo, lo que provoca que fluyan tra­n­s­fe­re­n­cias entre un modelo y otro.

La pro­gra­ma­ción tra­di­cio­nal funciona según el principio del monolito, im­ple­me­n­ta­n­do todas las tareas en una gran apli­ca­ció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 apli­ca­ción. El enfoque de mi­cro­se­r­vi­cios parte de la idea de los módulos, es decir, que cada mi­cro­se­r­vi­cio es re­s­po­n­sa­ble de una única tarea. Tan di­fe­re­n­tes como los re­su­l­ta­dos son los métodos de trabajo de ambas visiones.

Mientras en una ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios cada equipo se ocupa del de­sa­rro­llo de un mi­cro­se­r­vi­cio, en el de­sa­rro­llo con enfoque mo­no­lí­ti­co los equipos se organizan de forma diferente en función de la te­c­no­lo­gí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 re­s­po­n­sa­bles de publicar ac­tua­li­za­cio­nes, del ma­n­te­ni­mie­n­to y de la mo­ni­to­ri­za­ción. En el de­sa­rro­llo de un monolito todos los equipos dependen unos de otros. En una ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios, en cambio, el objetivo es evitar la in­te­r­de­pe­n­de­n­cia en lo posible.

En una ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios una apli­ca­ción se realiza a partir de pequeños módulos mo­no­fu­n­cio­na­les, los llamados mi­cro­se­r­vi­cios. Estos co­m­po­ne­n­tes se de­sa­rro­llan de forma aislada co­n­fo­r­ma­n­do entre todos el producto final. Esta ar­qui­te­c­tu­ra conlleva algunas ventajas:

En el de­sa­rro­llo de un mi­cro­se­r­vi­ce, los equipos trabajan de forma autónoma sin una instancia superior que indique el pro­ce­di­mie­n­to a seguir, ni la necesidad de coor­di­nar­se con el resto de equipos en todo momento. La atención del equipo se centra en la tarea, en la utilidad del mi­cro­se­r­vi­cio. La ventaja de este método de trabajo es que es el equipo de de­sa­rro­lla­do­res el que escoge la vía más adecuada al mi­cro­se­r­vi­cio en que trabajan y no la que otros han pensado. Esto es así hasta el punto de que es posible incluso utilizar lenguajes de pro­gra­ma­ción di­fe­re­n­tes para diversos mi­cro­se­r­vi­cios o im­ple­me­n­tar bases de datos o sistemas para ge­s­tio­nar­las de pro­du­c­ción propia. Esto es posible porque cada mi­cro­se­r­vi­cio posee su propio entorno de ejecución.

Como resultado de la in­de­pe­n­de­n­cia, el sistema se hace más robusto. Si un mi­cro­se­r­vi­cio falla, no se ve afectada la apli­ca­ción entera, sino solo un aspecto y, como se trata de un proceso de tamaño razonable, el error se puede encontrar fá­ci­l­me­n­te. En lugar de explorar el farragoso código fuente de un gran monolito solo es necesario analizar un programa re­la­ti­va­me­n­te pequeño.

En este contexto puede hablarse también de entrega continua (co­n­ti­nuous delivery), me­to­do­lo­gía por la cual algunos productos de software se mantienen en constante de­sa­rro­llo. Los mi­cro­se­r­vi­cios permiten a los fa­bri­ca­n­tes no tener que pla­ni­fi­car y gestionar grandes ciclos de ac­tua­li­za­cio­nes, porque los cambios in­tro­du­ci­dos en los mi­cro­se­r­vi­cios se van pu­bli­ca­n­do di­re­c­ta­me­n­te, siempre tras una fase de prueba, sin depender del resto de procesos. Los más pequeños cambios en un monolito de de­s­plie­gue, en cambio, implican ya un gran esfuerzo. Modificar un mi­cro­se­r­vi­cio 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 mi­cro­se­r­vi­cio está es­pe­cia­li­za­do y puede llevar a cabo los cambios sin grandes di­fi­cu­l­ta­des. Además, solo se admite un cambio por versión en el código fuente, sea una ca­ra­c­te­rí­s­ti­ca nueva o la re­pa­ra­ción de un error, lo que co­n­tri­bu­ye también a la rapidez en la in­tro­du­c­ción de mo­di­fi­ca­cio­nes y, con ello, a asegurar la es­ta­bi­li­dad del sistema completo a largo plazo.

Al final todos los co­m­po­ne­n­tes se encajan y a pesar de lo diferente que pueda ser la es­tru­c­tu­ra de cada mi­cro­se­r­vi­cio, 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 de­sa­rro­lla­do­res confían en APIS REST. Por medio de los cohe­re­n­tes y ligeros métodos HTTP, como GET o POST, cada mi­cro­se­r­vi­cio puede co­mu­ni­car­se fá­ci­l­me­n­te con los demás e in­te­r­ca­m­biar la in­fo­r­ma­ció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 ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios, en cambio, permite a los de­sa­rro­lla­do­res escalar con un grado de detalle excelente. Solo es necesario fo­r­ta­le­cer el servicio que lo requiere, lo que co­n­tri­bu­ye a que el producto final sea mucho más ligero y parco en recursos. Del mismo modo, integrar un servicio co­m­ple­ta­me­n­te nuevo en el sistema no requiere tanto trabajo.

Los mi­cro­se­r­vi­cios se mantienen aislados los unos de los otros y se ejecutan en su propio entorno. Solo se comunican entre sí a través de in­te­r­fa­ces. Con objeto de conseguir este ai­s­la­mie­n­to puede re­cu­rri­r­se a di­fe­re­n­tes opciones:

• Co­n­te­ne­do­res: la forma quizá más común de de­sa­rro­llar una ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios es la basada en co­n­te­ne­do­res. Estos re­pre­se­n­tan un método muy ligero de vi­r­tua­li­za­ció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 co­n­te­ne­do­res, los mi­cro­se­r­vi­cios son co­m­ple­ta­me­n­te 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 mi­cro­se­r­vi­cio. También en este caso cada uno de ellos puede funcionar de forma aislada del resto. El problema de este formato frente a una te­c­no­lo­gía de co­n­te­ne­do­res 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 mi­cro­se­r­vi­cio. En la práctica, sin embargo, esto re­su­l­ta­ría en un derroche de recursos, motivo por el cual suele optarse por la vi­r­tua­li­za­ción. Con todo, lo más im­po­r­ta­n­te, sea cual sea la elección, es que se dé un ai­s­la­mie­n­to real. No se re­co­mie­n­da ni ejecutar varios mi­cro­se­r­vi­cios en un único servidor ni todos juntos en un co­n­te­ne­dor. Esto podría provocar co­n­fli­c­tos entre las diversas apli­ca­cio­nes.

Para evitar so­bre­ca­r­gas en el sistema se utilizan ba­la­n­cea­do­res de carga, que reparten la carga au­to­má­ti­ca­me­n­te entre las di­fe­re­n­tes in­s­ta­n­cias para evitar fallos.

La ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios 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 mo­no­lí­ti­cos co­n­so­li­da­dos, se deciden por desmontar su ar­qui­te­c­tu­ra y cambiarla por los mi­cro­se­r­vi­cios. Compañías in­fo­r­má­ti­cas 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 mo­no­lí­ti­co, hasta que en 2008 un error en una base de datos provocó una in­te­rru­p­ción del servicio durante cuatro días. A partir de este momento se decidió de­sin­te­grar el antiguo sistema y dividirlo en mi­cro­se­r­vi­cios. Con esto se logró que la empresa pudiera lanzar los cambios mucho más rá­pi­da­me­n­te y que las re­pa­ra­cio­nes también pudieran llevarse a cabo con mucha más agilidad. Como el sistema de Netflix es muy extenso, la empresa de­sa­rro­lló un programa propio para coordinar los di­fe­re­n­tes mi­cro­se­r­vi­cios entre sí: este se conoce como Conductor.

Conductor permite que Netflix pueda gestionar los mi­cro­se­r­vi­cios de forma central (pausar o reiniciar) o es­ca­lar­los. En el núcleo del programa trabaja un servicio de nombre Decider que puede pla­ni­fi­car los procesos de forma au­to­ma­ti­za­da y reac­cio­nar a eventos en el workflow. Otros programas de­sa­rro­lla­dos por Netflix para trabajar efi­ca­z­me­n­te con mi­cro­se­r­vi­cios son Mantis (Stream pro­ce­s­si­ng), Dynomite (datastore) y Vizceral (traffic intuition).

Spotify, otro popular servicio de streaming, también apuesta por los mi­cro­se­r­vi­cios. El mayor desafío al que la empresa debe hacer frente a diario es la enorme co­m­pe­te­n­cia: con Amazon, Apple y Google, el mercado del streaming de audio tiene a algunas de las empresas in­fo­r­má­ti­cas más poderosas del mundo como co­m­pa­ñe­ros de equipo. Al mismo tiempo, los de­sa­rro­lla­do­res, debido al in­cre­me­n­to sostenido de su­s­cri­p­to­res, han de cubrir una demanda en constante cre­ci­mie­n­to y observar ciertas reglas propias del negocio, como los derechos de licencia. Para poder responder con rapidez a las in­no­va­cio­nes de la co­m­pe­te­n­cia y publicar las suyas propias aún más rápido, los mi­cro­se­r­vi­cios co­n­s­ti­tu­yen la solución adecuada para Spotify. La función por la cual los usuarios obtienen posibles re­su­l­ta­dos cuando teclean un término en su buscador, por ejemplo, es un mi­cro­se­r­vi­cio cerrado en sí que tiene a su propio equipo re­s­po­n­sa­ble.

Spotify también saca provecho de la co­n­si­s­te­n­cia propia de la ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios: cuando un mi­cro­se­r­vi­cio falla, el producto completo no se ve afectado. En total pueden contarse más de 800 mi­cro­se­r­vi­cios activos en Spotify. Para una gran parte de ellos, la empresa utiliza Java, y no porque no puedan es­cri­bi­r­se en lenguajes di­fe­re­n­tes, sino por mantener el flujo de trabajo: como los pro­gra­ma­do­res cambian co­n­s­ta­n­te­me­n­te de equipo, el trabajo es más viable si todos utilizan el mismo lenguaje.

La pla­ta­fo­r­ma de ventas eBay comenzó, como la mayoría de sistemas, como uno mo­no­lí­ti­co, pero con el tiempo acumuló 3,4 millones de líneas de código en un único archivo. Esto llevó a la empresa a pla­n­tear­se romper el monolito y de­sa­rro­llar mi­cro­se­r­vi­cios 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 mo­no­lí­ti­co por la ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios y lo hayan logrado con éxito demuestra los be­ne­fi­cios de este moderno pro­ce­di­mie­n­to. Si en los primeros días de un proyecto online con pocos usuarios activos y una oferta modesta una apli­ca­ción mo­no­lí­ti­ca es su­fi­cie­n­te, a medida que se van in­cre­me­n­ta­n­do los re­que­ri­mie­n­tos, el sistema se convierte en un ente torpe y estático que dificulta el cre­ci­mie­n­to.

Aun siendo muchos los factores que hablan a favor del de­sa­rro­llo de sistemas basados en mi­cro­se­r­vi­cios, este método no tiene que ser la mejor solución para cualquier empresa o proyecto. Es­pe­cia­l­me­n­te para programas in­fo­r­má­ti­cos sencillos que han de so­lu­cio­nar pocas tareas, la uti­li­za­ción de mi­cro­se­r­vi­cios puede conllevar un esfuerzo co­m­pa­ra­ble­me­n­te mayor porque, además de la creación de los servicios, su ma­n­te­ni­mie­n­to, su de­sa­rro­llo posterior y su mo­ni­to­ri­za­ción también si­g­ni­fi­can mucho trabajo. Pre­ci­sa­me­n­te es durante el control de los procesos cuando se ha de sopesar de la forma más exacta posible si los mi­cro­se­r­vi­cios lo favorecen o lo pe­r­ju­di­can, 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 mi­cro­se­r­vi­cios es la autonomía de los distintos equipos, que tiene el objetivo de evitar, por ejemplo, que un equipo tenga que esperar a los re­su­l­ta­dos de otro. Sin embargo, cuando el equipo entero solo se compone de unas pocas personas, tal se­pa­ra­ción pierde su sentido. Además, y siguiendo la ley de Conway, un equipo pequeño que en la práctica no necesita di­vi­sio­nes y todo se soluciona en común persigue un fin distinto.

También en los grandes equipos la in­tro­du­c­ción de este enfoque requiere un cambio profundo. Los puestos que dirigen el de­sa­rro­llo suelen des­apa­re­cer, porque los equipos se organizan a sí mismos. Una re­es­tru­c­tu­ra­ció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 pa­r­ti­da­rios de las ar­qui­te­c­tu­ras de mi­cro­se­r­vi­cios re­co­mie­n­dan en co­n­se­cue­n­cia una es­tra­te­gia Monolith first. Según esta, al comienzo conviene iniciar un proyecto como monolito y agotar las ventajas de esta co­n­ce­p­ción sobre todo en los primeros días. Solo cuando el proyecto ya ha adquirido una en­ve­r­ga­du­ra su­fi­cie­n­te debería cambiarse a una ar­qui­te­c­tu­ra de mi­cro­se­r­vi­cios. Entre ambos sistemas se encuentra la ar­qui­te­c­tu­ra orientada a servicios o SOA, adecuada como paso in­te­r­me­dio y con la cual también se procede con módulos. Aquí, cada uno de los servicios re­pre­se­n­ta procesos de negocio.