Una introducción a los Microservices

Últimamente ha habido mucho debate y hype alrededor de los Microservices. Pero, ¿qué son los microservices? ¿Por qué hay tanto ruido alrededor de un término? Espero que este post introductorio te ayude a entender qué es un microservice y a introducirte en el tema.

Foto de Glen Carrie

¿Qué son los Microservices?

Parafraseando a Martin Fowlers en su artículo sobre Microservices, “el estilo arquitectónico de microservices es un enfoque para desarrollar una única aplicación como un conjunto de pequeños servicios, cada uno corriendo en su propio proceso y comunicándose mediante mecanismos ligeros, a menudo una API de recursos HTTP”. Aunque hace referencia a las APIs HTTP, no es el único mecanismo para comunicar servicios, pero se está convirtiendo en el más utilizado debido a la creciente popularidad de los web services.

Es bastante común que la gente se confunda entre librerías y microservices cuando lee sobre el tema por primera vez. No te preocupes, nos ha pasado a todos. Se diferencian en que las librerías corren en el mismo proceso que la aplicación principal, y se comunican mediante llamadas a funciones dentro del propio proceso. Otro error común es confundir una arquitectura basada en microservices con una arquitectura modular. Aunque son similares, no son exactamente lo mismo. Es cierto que los microservices son implícitamente modulares, pero es falso que toda arquitectura modular use microservices. De hecho, la mayoría de las aplicaciones modulares son monolíticas.

Como desarrolladores, a veces tendemos a organizar nuestro código en torno a características técnicas, como frontend, backend, helpers, librerías, etc. Los microservices se organizan en torno a capacidades de negocio y por eso a menudo se confunden con los módulos de una aplicación modular. Significa que cada servicio realiza una función de negocio y dentro de ese servicio puedes organizar el código como quieras. Puedes pensar en un servicio como una aplicación independiente capaz de correr sola y que tiene valor por sí misma.

“Smart endpoints and dumb pipes” — con esa frase la comunidad de microservices intenta resumir cómo debería estructurarse la aplicación en términos de comunicación. La parte inteligente de la aplicación debería residir en los servicios (endpoints) y la comunicación debería hacerse lo más simple posible, usando APIs REST o colas de mensajes, como RabbitMQ o ZeroMQ. De hecho, las colas de mensajes son el segundo enfoque más utilizado para comunicar servicios, especialmente aquellos que ejecutan operaciones de larga duración o no son de alta prioridad. Por ejemplo, si un servicio necesita comunicarse con otro que simplemente envía emails, las colas de mensajes son una buena opción.

Pros y contras

El término microservice lleva años existiendo, pero últimamente, a medida que crecen los web services, está generando bastante hype a su alrededor. No es la solución definitiva para todas tus arquitecturas de aplicación, por eso debes ser consciente de los pros y los contras.

> Diseño evolutivo

Esta es probablemente una de las mayores ventajas de la arquitectura de microservices. A medida que tu aplicación crece, es fácil enchufar nuevos servicios con nuevas capacidades de negocio. Como la mayoría de las aplicaciones de software están orientadas al negocio y el mercado cambia tan rápido, acabarás adorando esta ventaja.

> Múltiples lenguajes de programación

Cada vez que empiezas una aplicación tienes que decidir en qué lenguaje la vas a construir. A veces eliges uno según tus habilidades y a veces según la mejor opción para la aplicación en cuestión. Con el tiempo, a medida que tu aplicación crece, acabas teniendo que ceñirte al lenguaje de programación elegido y a las tecnologías relacionadas. Entonces te das cuenta de que algunas funcionalidades nuevas rendirán mejor en otro lenguaje/framework. O peor aún, que esa tecnología no tiene una librería para usar con tu lenguaje de programación. Aquí es donde los microservices pueden ayudar mucho. Como cada servicio es una aplicación desacoplada e independiente, puedes usar un lenguaje/tecnología diferente para cada uno, según tus necesidades. Así que, por ejemplo, tu aplicación está escrita en Ruby on Rails y quieres integrar un chat usando Node.js.

> Múltiples tipos de bases de datos

De forma similar a lo descrito antes, puedes tener diferentes tipos de bases de datos en tu aplicación. Por ejemplo, digamos que tu aplicación usa MySQL para manejar la mayoría de los datos relacionales, pero para un chat quizá prefieras usar una base de datos de series temporales como InfluxDB. No soy experto en bases de datos, no te tomes al pie de la letra qué tipo de BD es la mejor para un chat, es solo un ejemplo.

> Unidades desplegables independientes

Como dije antes, un microservice es una aplicación independiente y, como tal, se puede desplegar de forma independiente. Significa que cada vez que necesitas cambiar un servicio no es necesario volver a desplegar toda la aplicación. Te hará sentir más seguro cuando estés a punto de hacer un despliegue.

> Resiliencia del sistema

Como sistema desacoplado y distribuido, cuando alguno de los servicios falla (y lo hará) solo fallará una función de tu aplicación, pero la aplicación seguirá siendo usable. Además, puedes tener un servicio monitorizando el resto de los servicios y si uno de ellos falla, reiniciarlo.

> Fácil de escalar

Imagina que tu aplicación permite subir imágenes y aplicarles efectos. Algunos de estos efectos pueden consumir mucha memoria y no quieres que eso afecte al resto de la aplicación. Usando microservices puedes añadir fácilmente memoria (u otros recursos) al servidor/proceso que ejecuta ese servicio. Es fácil escalar recursos según las necesidades del servicio.

> Lidiar con demasiados servicios

Cuando estás decidiendo en cuántos servicios quieres dividir tu aplicación, es fácil volverse loco con los límites de los servicios y acabar teniendo un montón de servicios que tendrás que desarrollar y mantener. Será muy fácil introducir complejidad innecesaria en el sistema y, por tanto, errores. Ten cuidado con eso.

> Duplicación de código

Del mismo modo que es agradable tener la posibilidad de usar diferentes lenguajes de programación, también es muy fácil tener el mismo código en distintos lenguajes. Cuando ocurre dentro del mismo lenguaje, algunas personas sugieren usar este código como una librería, pero entonces estarás introduciendo acoplamiento.

> Testing

El testing es un pro y un contra. Aunque es bastante fácil testear un único servicio, puede ser un dolor testear todo el sistema y su integración, ya que cada vez que quieres testear la aplicación entera tienes que configurar y levantar cada servicio.

> Asincronicidad

Las operaciones asíncronas introducen complejidad en su coordinación y lo hacen realmente difícil cuando necesitas operaciones síncronas o transaccionales.

Muchas de estas no son realmente una desventaja, sino simplemente una falta de herramientas para automatizar o monitorizar. Como dice un amigo mío: “¡Necesitamos una herramienta!”.

¿Debería estar usando Microservices hoy?

Esa es una gran pregunta que escucho a menudo. Empezaría analizando cuidadosamente las necesidades de la aplicación. Mi consejo es que es mejor empezar pequeño y sencillo, pero sin dejar de tener en cuenta que tu aplicación puede crecer y no quieres sufrirlo, sino disfrutarlo. Sé pragmático, no dogmático. Es cierto que hay prácticas bien conocidas que funcionarán para tu aplicación, pero no tengas miedo de adaptarlas a tus necesidades.

Un enfoque común que yo también sigo es empezar la aplicación de forma monolítica pero modular. Después de esto, empezar a separar estos módulos en servicios según los vayas necesitando realmente. No será fácil, ya que cada llamada dentro del proceso que hicieras tendrás que reescribirla como una Remote Procedure Call, necesitarás montar un nuevo servidor/proceso con sus propios recursos y configurarlos, pero créeme, será más fácil que tener que empezar con una aplicación fuertemente acoplada.

Form Follows Function

Este título es un extracto de una bonita cita de Louis Sullivan:

“Whether it be the sweeping eagle in his flight, or the open apple-blossom, the toiling work- horse, the blithe swan, the branching oak, the winding stream at its base, the drifting clouds, over all the coursing sun, form ever follows function, and this is the law. Where function does not change, form does not change.” — Louis Sullivan

***
por Francisco Méndez Vilas
Full Stack Developer en Redbooth

Referencias

• http://martinfowler.com/articles/microservices.html (Post de James Lewis y Martin Fowler sobre Microservices)
• http://www.infoq.com/minibooks/emag-microservices (Una lectura interesante sobre microservices, con muchos casos de uso reales)
• http://samnewman.io/blog/2015/04/07/microservices-for-greenfield/ (Artículo de Sam Newman sobre usar Microservices desde el principio en un proyecto greenfield)