Arquitectura de Microservicios
Antecedentes
El modelo de Arquitectura de Microservicios (Microservices Architecture) es un nuevo término que se ha hecho conocido poco a poco en los últimos años en la comunidad del desarrollo de software. El término fue creado por un grupo de arquitectos de software en 2012, pero recién en 2014 empezó hacerse conocido, cuando Martín Fowler, desarrollador de software y autor conocido de la comunidad, comenzó a usar el término en algunas de sus publicaciones de su página web. En la siguiente figura podemos notar cómo fue el crecimiento del término en Google [Ver figura 1].
Definición
(Lewis J., +, 2014)
En resumen, el estilo arquitectónico de microservice es un enfoque para el desarrollo de una sola aplicación como un conjunto de servicios pequeños, donde cada uno se ejecuta en su propio proceso y comunicación con mecanismos de peso ligero, a menudo una API recurso HTTP. Estos servicios se construyen en torno a las capacidades de negocio y se despliegan independientemente por un mecanismo de implementación totalmente automatizado. Hay una mínima gestión centralizada de estos servicios, que pueden estar escritas en lenguajes de programación diferentes y utilizan diferentes tecnologías de almacenamiento de datos.
Si bien no existe una definición precisa de este estilo arquitectónico, podríamos decir que es una forma de construir aplicaciones distribuidas, conformada por un conjunto de componentes de servicios pequeños, los cuales pueden ser desplegadas de forma independiente y escalables según sea necesario, y donde los servicios pueden ser desarrollados en diferentes lenguajes de programación y gestores de base de datos.
A continuación mostraremos la diferencia entre hacer una aplicación monolítica y una que usa Arquitectura Microservices [Ver figura 2].
¿Cómo funciona?
(Manfred Bortenschlager, 2016)
Los microservicios se comunican a través de las API. Hay una distinción importante entre APIs para microservicios que se invocan dentro de los límites del sistema (APIs internas) y llamadas API que se emiten desde fuera (APIs externas). Todas estas API deben gestionarse, pero dependiendo del contexto empresarial y arquitectónico, pueden existir diferencias entre la gestión de la API para las API internas y externas. El siguiente diagrama (figura 3) describe un MSA con las diferentes rutas de comunicación entre microservicios habilitados a través de APIs. Las API externas se indican con círculos sólidos. Las API internas en los límites del sistema están segmentadas.
Este diagrama muestra un par de otros conceptos importantes. Dentro de los límites del sistema, hay una serie de microservicios individuales. Además, hay grupos de microservicios o módulos. Estos son conjuntos cohesivos de microservicios que juntos forman un servicio específico de nivel superior. Por ejemplo, un servicio de tienda en línea puede ser un servicio de nivel superior que requiera varios servicios como servicios de pago, servicio de carrito de compras, servicio de lista de deseos, servicio de recomendación y más.
Orquestación y coreografía de microservicios
Los microservicios en conjunto suelen ser orquestados o coreografiados. Orquestar significa que hay una entidad central (idealmente un microservicio en sí mismo) que coordina la comunicación entre varios servicios. Mientras que para microservicios coreografiados, los diversos microservicios se manejan. El enfoque orquestado es más fácil de lograr. Sin embargo, resulta en dependencia y un solo punto de falla para el servicio de coordinación. Ambos tienen sus pros y sus contras, y cómo diseñar su MSA depende de su contexto particular.
La capa de agregación ayuda en la gestión de servicios
Otro concepto efectivo mostrado en el diagrama es la capa de agregación API, mostrada en la parte superior. Como su nombre sugiere, esta capa agrega varios servicios individuales y grupos de microservicios en los servicios que luego son expuestos a los consumidores de API. Esto se relaciona con el concepto de diseñar APIs por simplicidad, ya que la capa de agregación combina los servicios y proporciona API según los casos de uso más comunes. Este enfoque también hace que sea más fácil mantener o cambiar los servicios individuales porque hay otra capa de abstracción y no hay acceso directo al microservicio. Un ejemplo de diseño para la flexibilidad es la segunda API externa, que conecta directamente el grupo de microservicios A. ¿Qué tan simples o flexibles son las API de su MSA? Depende, una vez más, de su contexto particular: el dominio de su negocio y las necesidades de los consumidores de API.
El patrón Backend para Frontend (BFF) acreditado a Phil Calcado es un refinamiento de la capa de agregación API. En términos simples, BFF es una fachada característica específica que se encuentra en el lado del servidor y proporciona API personalizadas y optimizadas para ciertos tipos de clientes y sus plataformas, como los navegadores web o las aplicaciones móviles. La idea es tener varios BFFs, dependiendo de cuántos diferentes canales de este tipo debe ser apoyado y lo diferentes que son los clientes. Con este patrón, las estrategias de omni-canal se pueden implementar más eficazmente. Idealmente, BFFs son también microservicios.
Casos reales
Netflix
(SmartBear S., 2015)
En el 2009, Netflix comenzó a trasladarse de una arquitectura monolítica a una arquitectura de Microservices AWS basados en la nube, mucho antes que existiera el término Microservices. Netflix primero comenzó con el traslado de codificación de película, una aplicación no orientada al cliente. En 2010, Netflix comenzó a trasladarse a partes orientadas al cliente de la página web de AWS incluyendo la cuenta a inscribirse, selecciones de películas, las selecciones de televisión, los metadatos y la configuración del dispositivo. A finales de 2010, la totalidad del sitio web orientado al cliente había sido trasladado a AWS. Para diciembre de 2011, Netflix había sido trasladado con éxito a la nube, rompiendo su monolito en cientos de microservicios de grano fino.
Razones para el traslado a una Arquitectura de Microservicios
Hubo una serie de razones, Netflix tomó la decisión de trasladarse de un centro de datos monolítico a una arquitectura de microservices basado en la nube. Las principales razones para el traslado tuvieron que ver con la disponibilidad, la escala y la velocidad. La compañía necesitaba una arquitectura que permita a Netflix cumplir con los siguientes atributos de calidad de software:
- Disponibilidad 24/7, el número de usuarios Netflix iba en crecimiento porque se podía acceder mediante plataformas de videojuegos (Xbox y Wii) y dispositivos móviles, así que su expansión fue nivel mundial.
- Escalabilidad para mantenerse al día con su tasa de crecimiento. Ahora Netflix es capaz aumentar o disminuir su capacidad en minutos con AWS nube. Si es necesario satisfacer la creciente demanda de servicios, miles de instancias de servidor se pueden formar simultáneamente.
Proceso de traslado a una Arquitectura de Microservicios
Mientras que la plataforma de Netflix es uno de los mejores ejemplos de la arquitectura moderna de microservices basado en la nube, el paso de monolito a microservices, tuvo algunos problemas. Cuando Netflix movió primero el sitio web orientado al cliente a la nube, había una gran cantidad de problemas de latencia con las páginas web. Una de las maneras con las que Netflix trato este tema, fue mediante la gestión de los recursos dentro de AWS, para ajustarse a la creación de redes de AWS que cuenta con más latencia variable que los centros de datos de Netflix.
En abril del 2011, hubo un corte de luz en AWS — Este de Estados Unidos que provocó la caída de varios sitios web populares alojadas en AWS. Mientras que Netflix no experimentó ninguna de las grandes interrupciones externas, porque la empresa tuvo que hacer cambios manuales en su motor de configuración de conjuntos de servicios AWS fuera de las zonas de disponibilidad de Amazon. Desde entonces, la compañía ha automatizado gran parte del proceso, por lo que las fallas de esta naturaleza son manejadas sin necesidad de una gran cantidad de intervención manual por los ingenieros de Netflix.
Netflix se enfrentó a una serie de problemas, ya que constantemente se migraba a una arquitectura basada en la nube, tales como aumentos de la carga, fallos de instancia, fallas de zona/ región y los problemas de rendimiento. Netflix ha construido muchas tecnologías y herramientas para ayudar a abordar y resolver estos problemas.
Herramientas usadas por Netflix
(Datawire, 2016)
Netflix también hace uso de un elevado procesamiento de datos a través del uso de herramientas como Genie. Por medio de este, Netflix permite a los desarrolladores presentar nuevos clusters desde el otro lado de sus pruebas, desarrollo y entornos de producción a la vez con configuración y despliegue de trabajos pendientes. La elevación de datos permite a los desarrolladores escalar mejor sus microservices para satisfacer las necesidades de los clientes, mientras que también permite un mayor procesamiento de datos eficiente. Los clusters pueden ser añadidos o terminados basándose en la carga de un clúster, esto representa un ahorro significativo para aquellos que trabajan con grandes cantidades de datos a escala.
Referencias
(Lewis J., +, 2014): Lewis James, Fowler Martin (2014). Guía de Recursos Microservices. Recuperado de la URL.
(Datawire, 2016): Datawire IO (2016). Microservices en Netflix: Detener problemas de sistemas antes que empiecen. Recuperado de la URL.
(SmartBear S., 2015): SmartBear Software (2015). ¿Por qué usted no puede hablar de Microservices sin mencionar a Netflix? Recuperado de la URL.
(Manfred Bortenschlager, 2016): Logrando la Agilidad de la empresa con Microservices y Gestión de API.
Índice de figuras
(Google Trends, 2015): Figura 2.2–1, Google Trends, Interés de búsqueda del termino Microservices a lo largo del tiempo 2013–2015. Recuperado de la URL.
Google Trends
Explore search interest by time, location and popularity on Google Trends
www.google.com
(Fowler M., 2014): Fowler, A. Martin (2014). Microservices. Recuperado de la URL.
