En post anteriores ya hemos visto que es la arquitectura de software, para que nos sirve y algunas de las más usadas con sus pro y contras.

En este nuevo post vamos a ver una arquitectura relativamente nueva y muy difundida, la arquitectura de microservicios. Es implementada por grandes empresas como Netflix, Spotify y otros por sus ventajas y además existen muchas contribuciones de la comunidad para que las desventajas que esta posee no sean difíciles de llevar.

¿Qué es la arquitectura de microservicios?

La arquitectura de microservicios tiene como pauta principal el crear un sistema conformado por pequeños sistemas independientes. Es decir, por ejemplo, imaginemos el sistema de netflix. En este podemos hacer muchas operaciones además de ver series, como crear un usuario, pagar mi suscripción, calificar una serie, etc. En vez de que todo lo resuelva una gran aplicación monolítica (un único paquete que resuelve todo), que pasaría si cada pequeña operatoria es resuelta por una aplicacion específica. O sea, tendríamos una aplicación encargada de la gestión de usuarios, otra encargada de la facturación y así con cada funcionalidad. Obviamente para la facturación voy a necesitar datos del usuario, es decir, de la otra aplicación. Es por esto que las aplicaciones también hablan entre sí para ofrecerse servicios entre ellos y al cliente final.

Parte de la problemática que presenta esta definición es ¿Qué tan chico tengo que hacer cada módulo? Bueno, no existe una definición exacta, simplemente cada módulo debería encargarse de una parte específica del sistema (un poco como dice la separación de clases por responsabilidades).

Para generar el menor aclople entre estas aplicaciones, la arquitectura establece que cada pequeño modulo debe manejar su propio dominio independiente de las otras. Por ende tambien debe manejar su propia estructura de datos para ser almacenados.

Ejemplo de una posible infraesctructura de microservicios.

Ventajas

Las principales ventajas que posee esta arquitectura están relacionadas con que sean pequeños módulos con responsabilidades únicas:

• Facilidad de testeo. Ya que puedo probar cada módulo pequeño que haya sufrido cambios sin necesidad de probar todo el sistema completo, esto es un poco mas problemático cuando una operatoria depende de otros módulos, pero si tenemos bien montada la infraestructura de nuestro sistema, no debería presentar mas problemas.
• Facilidad de deploy. Si bien la infraestructura va a ser más compleja, la ventaja de deployar solo una parte del sistema es mucho mejor que tener que deployar el sistema completo.
• Escalabilidad. Como cada módulo tiene responsabilidad única, es más fácil y barato instanciar más instancias solo del módulo que más está siendo usado y no tener que levantar todo el sistema completo ante un incremento de uso de solo una parte del sistema.
• Tolerante a fallos. Si un módulo comienza a fallar solo se perderá parte del sistema, haciendo que por ejemplo si se calló el módulo de usuarios no se podrá gestionar usuarios, pero si se podrá seguir viendo películas. Obviamente existen módulos más críticos ya que son más utilizados por los demás.
• Diseño evolutivo. Cada módulo puede evolucionar por sí mismo sin que se afecte todo el sistema. Es decir, puedo agregar muchas funcionalidades a la gestión de usuarios, pero sin tocar el módulo de facturación.
• Implementación en distintas tecnologías. Como cada módulo es independiente del resto, nada limita que un módulo pueda ser desarrollado en java mientras que otro puede estar en go, por ejemplo.

Desventajas

Del mismo modo que tener pequeños módulos tiene sus cosas lindas, también trae sus problemas:

• Infraestructura: En mi opinión este es uno de los principales problemas que trae esta arquitectura. Si bien levantar una sola aplicación es relativamente fácil una vez configurado mi ambiente, imaginen esto con muchas, muchas aplicaciones. ¿Que modulo interactua con que otro modulo?, ¿En qué puerto de desplegó la instancia x de tal modulo? ¿Que properties utiliza quién?, etc.
  De igual manera como mencionamos anteriormente, ya existen en el mercado muchas herramientas open source y pagas, que están pensadas para solucionar estos problemas, por ejemplo spring cloud, ofrece varios módulos cada uno para solucionar distintas problemáticas que esta arquitectura presenta, como ser Eureka discover (descubre cuando se levanta una nueva instancia y se la informa a los demás para que la utilicen), hystrix (permite el corte de la comunicaciones si un módulo comienza a arrojar fallos), y otros. Y entre los más conocidos, pagos, se encuentra AWS (Amazon) que provee muchísimas herramientas para todo lo que es microservicio, obviamente por un lindo precio U$D.
• Mayor latencia interna: Como cada módulo se comunica con otros esto puede provocar un mayor tráfico de red, lo cual podría significar un problema.
• Versionado: Es costoso si evolucionamos módulos en distintas versiones saber que modulo sigue siendo compatible con otro. Y más aún si mantenemos varias versiones del sistema vivas al mismo tiempo. Esto también se solventa con una buena infraestructura montada y aprovechando el uso de herramientas que nos ayuden a resolver la compatibilidad entre versiones.
• Uso memoria: Si nuestro sistema crece en cantidad de módulos, la memoria del nodo puede tener que crecer para dar abasto.

Hasta aquí fue un poco de esta arquitectura de microservicios. Espero tengan la posibilidad de implementarla y compartan su experiencia con la comunidad.