jueves, 22 de septiembre de 2016

Introducción a Microservicios

Para construir aplicaciones orientadas a servicio, los más habitual es crear una aplicación monolítica, bajo la esquema clásico Model-View-Controller, con un único contenedor que incluye tanto la lógica de negocio como la interfaz de usuario.

Cuando estas aplicaciones crecen y abarcan un gran conjunto de diferentes componentes, módulos y pruebas previas al despliegue; aumentan en proporción al crecimiento de la aplicación (aumento en los tiempos de pruebas, conflictos y revisión de código) en detrimento del tiempo de producción para desplegar y actualizar nuevas versiones en producción. Como solución a estos problemas surgen nuevos patrones de arquitectura como el mencionado aquí.  Pero, ¿qué son las aplicaciones basadas en Microservicios?

Una arquitectura basada en microservices divide el front-end y el back-end, por lo que es más fácil de distribuir, basado en los principios Reactivos para la construcción de un servicio aislado escalable, resistente a fallos y que se combina con otros servicios para formar un todo.
Ejemplo arquitectura microservicios con JHipster
Ejemplo de aplicación en arquitectura de Microservicios con JHipster.
Los microservicios son, en definitiva, una extensión de la arquitectura orientada a servicios para contruír sistemas distribuidos de software. La idea nace de mano del Doctor Peter Rodgers en 2005 introduciendo el término Micro-Web-Services en la presentación de la conferencia Cloud Computing Expo. Más tarde, Adrian Cockcroft en Netflix los describiría como "Arquitecturas Orientadas a Servicio de grano fino" y; James Lewis y Martin Fowler terminan por nombrar a este término como Microservicios:
La "Arquitectura Microservicio" ha surgido en los últimos años para describir una forma particular de diseñar aplicaciones de software como suites de servicios con despliegue independiente.
Si bien no existe una definición precisa de este estilo arquitectónico, hay ciertas características comunes en torno a la capacidad de negocio, el despliegue automatizado, la inteligencia en los puntos de control y el control descentralizado del lenguaje de programación y los datos.
Una aplicación con microservicios se basa en que la versión monolítica debe ser separada en proyectos completamente independientes y que estos se comuniquen entre sí, a través de servicios web, donde cada uno realizará su propia lógica de negocio. Una aplicación a modo de pasarela orquesta estos microservicios para proveerlos al cliente a través de una interfaz de usuario o front-end. Cuando se requiera refactorizar código o actualizar la versión de uno de estos microservicios, al ser completamente independientes se pueden lanzar las pruebas y asegurar la calidad. En caso de éxito en las pruebas, puede resultar sencillo desplegar la nueva versión del microservicio en producción sin afectar al resto.

Ver Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned por Ruslan Meshenberg en GOTO 2016:


Los microservicios contemplan las siguientes características y ventajas:
  • Facilitan el reemplazo de cada uno de los servicios, sin tener que eliminar todo el conjunto de la aplicación.
  • Los servicios se organizan por capacidades, por ejemplo interfaz de usuario, logística, facturación, etc.
  • Los servicios se pueden implementar con diferentes lenguajes de programación, bases de datos, hardware y entornos de software.
  • La arquitectura es simétrica y no jerárquica.
  • Se presta a un proceso de desarrollo de software de entrega continua. Un cambio de una pequeña parte de la aplicación sólo requiere uno o un número pequeño de servicios a ser reconstruidos y desplegados.
  • Obliga a crear una estructura modular.
Como desventajas destacan:
  • Los servicios constituyen barreras para la información. Se crearán varias fuentes de datos, que requieren comunicarse entre ellas y realizar varias copias, snapshots y recuperaciones.
  • La arquitectura introduce una complejidad adicional y nuevos problemas que resolver, como la latencia de la red, formatos de mensaje, equilibrio de carga y tolerancia a fallos.
  • Las pruebas y el despliegue son más complicados.
  • Entre las llamadas de los microservicios hay un mayor coste en términos de latencia de la red y el tiempo de procesamiento de los mensajes que en las llamadas en una aplicación monolítica.
  • Mover responsabilidades entre los microservicios es más difícil. Puede implicar la comunicación entre los diferentes equipos, refactorizar código de una funcionalidad en otro lenguaje o tener que hacerlo encajar en una infraestructura diferente.
Desde el 2015 el término microservices es bastante hype, ¿quién no desearía migrar su aplicación monolítica a microservicios? Si algún lector está pensando en hacerlo, recomiendo el leer el artículo de Arun Gupta Monolithic to Microservices Refactoring for Java EE Applications y ver el siguiente que presenta en la conferencia Devoxx de 2015 "Refactor your Java EE application using Microservices and Containers":




Fuentes: