En este post discutiremos cómo funcionan los microservicios, cuáles son sus ventajas y a qué debemos prestarle atención al momento de su implementación.

¿Qué es la arquitectura de microservicios?

A particular way of designing software applications as suites of independently deployable services.

La arquitectura de microservicios ha sido el término de moda en últimamente, pero la idea no es nueva en absoluto. De hecho, es bastante similar al patrón SOA que fue muy popular hace unos años. Tanto los microservicios, como SOA, se tratan de descomponer aplicaciones en servicios más pequeños para escalamiento y manejo de ciclos de vida más eficientes. Sin embargo, no son iguales, según lo explicado en un COMPLETO POST Martin Fowler. Mientras que SOA es un concepto general y puede significar muchas cosas, la arquitectura de microservicios describe un modo particular de construir aplicaciones con servicios muy pequeños, cada uno de los cuales se enfoca en hacer sólo una cosa bien.

Hay dos razones por las cuales los microservicios están ganando popularidad. En primer lugar, como los aplicativos son cada vez más complejos, la arquitectura monolítica tradicional ya no cumple con las necesidades de escalabilidad y ciclo de desarrollo rápido -en la siguiente sección veremos cómo los microservicios lo hacen posible-. En segundo lugar, el éxito de grandes compañías de Internet, principalmente Netflix, al implementar la arquitectura de microservicios, es una gran motivación para que otras empresas consideren hacer el cambio.

¿Cómo funciona?

La mejor manera de explicar los microservicios es compararlos con la arquitectura de las aplicaciones monolíticas, así que hagamos una rápida recapitulación.

En el diseño tradicional de tres capas, el servidor de aplicaciones asume el rol de capa media al procesar la lógica de negocio y servir los datos desde la capa de base a los clientes (navegadores web, aplicaciones móviles, internet, etc.).  La aplicación está escrita como una única base de código, acoplada y todo se ejecuta en el mismo proceso.  El escalamiento se realiza mediante la replicación de la misma aplicación monolítica en múltiples servidores o instancias de ejecución (en la nube).

En la arquitectura de microservicios, la aplicación monolítica se descompone en múltiples servicios pequeños, granulares, aislados, independientes y distribuibles.  El hecho de que estos servicios se desacoplen por separado es trascendental, pues permite priorizar los recursos escasos a los microservicios más relevantes sobre los demás.  Estos servicios pueden ser desarrollados en paralelo, por diversos equipos, usando las tecnologías más adecuadas para cumplir con sus propósitos. También, como se desacoplan por aparte, pueden ser escalados de manera independiente.

Por ejemplo, un servicio que consume mucha CPU, pero no necesita tanta memoria, puede ser escalado en servidores equipados con un procesador potente, pero con menor memoria.  Podemos escalar solamente los servicios que deseamos y no es necesario escalarlos todos.

Cubo de escala – del libro El arte del escalamiento

Si los servicios son independientes y aislados, ¿cómo compartir código entre ellos? Bueno, es cuestión de encontrar el punto de equilibrio. Lo positivo de compartir código entre servicios es que permite reutilizar funcionalidades existentes y mantener el principio DRY (no escribir código duplicado); lo negativo es que aumenta el acoplamiento entre los servicios. Una solución es compartir solamente las librerías de utilidades técnicas y las de funcionalidades comunes; estas se pueden configurar como servicios independientes a los cuales otros servicios pueden llamar. Entonces, el siguiente punto a resolver a continuación es la comunicación entre servicios.

La comunicación entre estos microservicios puede implementarse de dos maneras, mediante peticiones HTTP y a través de cola de mensajes (Azure Service Bus, RabbitMQ, Kafka Apache, etc.). Básicamente, HTTP es comunicación directa y debe usarse cuando se desea una respuesta inmediata del otro servicio. Por otra parte, el mecanismo publicación/suscripción de la cola de mensaje tiende a ser asíncrono.

Finalmente, como los servicios son muy granulares, las aplicaciones-cliente generalmente necesitan interactuar con múltiples servicios para obtener los datos que necesitan. Para permitir cambios en los servicios sin afectar a los clientes, se utiliza una API Gateway. API Gateway es una capa abstracta que oculta a todos los microservicios, dejando un único Endpoint para que los clientes se comuniquen. Las solicitudes que lleguen al Gateway serán procesadas/enrutadas hacia los servicios específicos. El Gateway también nos permite monitorear fácilmente el tráfico y uso de los servicios.

Las ventajas

Mientras que la arquitectura monolítica funciona bien en escenarios tradicionales, en el mundo de hoy, donde las aplicaciones necesitan desplegar nuevas funcionalidades frecuentemente -en términos de horas- y estar siempre en línea con alta disponibilidad, este estilo arquitectónico no cumple con las expectativas.

Un cambio sencillo en un componente requiere pruebas de regresión, de recompilar y volver a desplegar toda la aplicación. Y dado que todo se ejecuta en el mismo proceso, una excepción no controlada puede afectar todo el sistema monolítico.

Por el contrario, la arquitectura de microservicios es mucho más flexible y resistente:

• Los servicios en sí son muy simples de construir, pues se centran en hacer solamente una cosa bien, de forma que son fáciles de probar y se puede asegurar mayor calidad.
• Cada servicio puede construirse con las tecnologías y herramientas más adecuadas, permitiendo “POLYGLOT PROGRAMMING” (las aplicaciones se deben escribir en una mezcla de lenguajes para explotar sus mejores características). La elección inicial de una tecnología no nos debería limitar durante el ciclo de vida del proyecto.
• Múltiples equipos de desarrolladores pueden trabajar independientemente bajo esta arquitectura. Esto es ideal para lograr el “continuous delivery”, pues permite actualizaciones frecuentes mientras el resto del sistema se mantiene estable.
• En el caso que un servicio deje de funcionar, solo afectará las partes que dependen directamente de él (si las hay). El resto seguirá funcionando bien.

Aspectos a prestar atención

Al igual que con los demás patrones y arquitecturas, la arquitectura de microservicios no es la solución absoluta a todos los problemas. Aunque soluciona muchos problemas de otros estilos arquitectónicos, también presenta nuevos inconvenientes que debemos considerar.

Por tener muchas partes modulares, los microservicios están en un nivel de complejidad distinto a la arquitectura monolítica. Se requiere una gran habilidad en DevOps para desplegar y mantener una aplicación de microservicios en producción. Mientras que la aplicación monolítica puede desplegarse en un pequeño clúster de servidores de aplicación, cada uno de los microservicios requiere su propio cluster para conmutación por fallas y resiliencia. También debe considerase adicionar balanceadores de carga y una capa de mensajería entre los clusters. Se requiere escribir los scripts de liberación automática para poder aprovechar la opción de “continuous delivery”.

Los sistemas de microservicios son distribuidos por naturaleza y como tal, son difíciles de construir. Un simple llamado (call) tradicional ahora podría convertirse en un llamado de procedimiento remoto (RPC), un REST o un mensaje asincrónico. Los desarrolladores necesitan pensar más en problemas como la latencia entre servicios, tolerancia a fallos, control de versiones, etc.  Aunque siempre es bueno tener estas propiedades en el sistema, con toda seguridad su construcción requiere más esfuerzo.

Y mientras que los servicios son más fáciles de probar por sí mismos, las pruebas de integración end-to-end son más difíciles. Como el flujo de código es complejo, puede ser difícil identificar en qué parte de la cadena se presentan los errores.

Conclusiones

La arquitectura de microservicios es una forma muy prometedora de diseñar y construir aplicaciones altamente escalables de manera ágil. Ya hemos visto los desafíos en la implementación de sistemas de microservicios. En mi opinión, la mayoría de ellos se resolverá en un futuro próximo, a medida que la arquitectura gane popularidad y se desarrollen más herramientas y marcos de trabajo para soportarla.

Redes sociales

• Linkedin: linkedin.com/in/jaimirg
• Twitter: @jaimirg
• Blog: HTTP://BLOGS.MSMVPS.COM/JAIMIRG/
• Facebook: FACEBOOK.COM/JAIMIR.GUERRERO

También nos puede encontrar en: https://www.designrush.com/agency/software-development/florida/miami