• Giovanny Rey Cediel

Arquitectura de Microservicios

Actualizado: ene 21




Chris Richardson, arquitecto de software especialista en microservicios, define los microservicios como: “Un estilo arquitectónico que estructura una aplicación como una colección de servicios que son: altamente mantenibles y testeables, débilmente acoplados, desplegables de forma independiente, organizados entorno a capacidades de negocio, y en propiedad de un pequeño equipo de desarrollo.” Fin de la cita.



Wikipedia en inglés, define la arquitectura de microservicios como: “una variante del estilo estructural de la arquitectura orientada a servicios (SOA), que organiza una aplicación como una colección de servicios débilmente acoplados.“ Fin de la cita.


Éstas definiciones sueltas dejan muchas dudas, así que vamos a analizar cada una de ellas. Primero vamos a analizar, ¿por qué se dice que los microservicios son una variante de la arquitectura orientada a servicios? Para responder esta pregunta tenemos que recordar lo que era una arquitectura orientada a servicios. Básicamente SOA, acrónimo de service-oriented architecture, se trataba de como construir, usar y combinar servicios, en lugar de crear un gran paquete de software que lo haga todo. Esta idea se gesta entre los años 2000 y 2005 aproximadamente, y es modelada al rededor de tres componentes y tres estándares. El consumidor de servicios, el proveedor del servicios y el registro de servicios. El proveedor de servicios y el consumidor de servicios se comunicaban mediante el estándar SOAP (Simple Object Access Protocol), por otro lado, la interfaz de los servicios era descrita mediante el estándar WDSL (Web Services Description Language), y como “broker” o intermediario entre proveedores y consumidores de servicios, estaba el estándar UDDI (Universal Description, Discovery, and Integration) que a su ves servía como directorio de servicios. La siguiente figura ilustra el concepto:



La idea con SOA, era que cada organización o entidad pudiera exponer sus servicios para que otras organizaciones o entidades los pudieran descubrir y posteriormente consumir. Por ejemplo, un banco podría proveer un API de servicios para realizar transferencias de dinero entre cuentas bancarias, esta API podría ser consumida por la aplicación de una empresa para realizar el pago de nómina de su personal. Es decir, SOA apuntaba a comerciar servicios a nivel empresarial, los cuales podrían verse como “macroservicios”, y esta es la diferencia fundamental con la arquitectura de microservicios, ya que el objetivo principal de los microservicios no es exponer servicios a nivel externo, sino dividir internamente una aplicación en pequeños servicios que interactuando en conjunto garantizan su funcionalidad. Luego, en los microservicios también es posible exponer al exterior algunos servicios internos, sin embargo, esto sería un objetivo secundario de la MSA (Microservice Architect). Otra diferencia con SOA es que los microservicios utilizan un mecanismo de comunicación más ligero.



El protocolo comúnmente usado para la comunicación entre microservicios es el HTTP, no existe un mecanismo de registros de servicios como el UDDI, sin embargo cuando hay un alto volumen de peticiones en la red, se levantan una serie de preocupaciones como balanceo de cargas, trazabilidad, descubrimiento de servicios, etc.


En los últimos años han surgido una serie de patrones enfocados a solucionar varios aspectos, entre ellos los relacionados con el incremento del tráfico de red. Por ejemplo, el patrón API Gateway (API de Puerta de Enlace) se usa para gestionar el tráfico externo (comunicación entre el cliente y los microservicios). El patrón Service Mesh (Malla de Servicios), se usa para solucionar problemas de comunicación interna; y como estos existen otros tantos patrones que pueden aplicarse según la necesidad. Como comentario al margen menciono que estos patrones —que se supone son la mejor solución a problemas típicos—, muchos ya han sido encapsulados en aplicaciones que conforman un gran mercado, y como todo en el mundo del software, existen soluciones de código abierto y otras con licencia comercial. Este tema de los patrones de microservicios [ Como comentario al margen, quiero mencionar que estos patrones,que se supone son la mejor solución a problemas típicos, muchos ya han sido encapsulados en aplicaciones que a su ves conforman un gran mercado, como todo en el mundo del software… hay soluciones de código abierto y otras con licencia comercial.


]es bastante amplio e interesante y seguramente lo trataré en otros artículos.



Ahora vamos a analizar, las cinco características que deben cumplir los microservicios, de acuerdo a la definición de Chris Richardson.


  1. Los microservicios deben ser altamente mantenibles y testeables. En otras palabras se desea que el desarrollo, el despliegue y las pruebas, se realicen rápidamente. Esto es posible gracias a que la aplicación se divide en pequeños fragmentos o microservicios independientes, los cuales son más fáciles de crear y mantener. La administración del código se vuelve más sencilla, ya que cada microservicio tiene su propio código fuente. Esta característica resulta útil para acelerar las pruebas de calidad, ya que cada microservicio se puede probar individualmente sin tener que esperar a desarrollarlos todos.

  2. Los microservicios deben ser débilmente acoplados. Esto se consigue ya que cada microservicio es un componente independiente, con su propio código fuente, y su propia base de datos, además no comparte responsabilidades con otros microservicios, es decir, cada microservicio tiene una única responsabilidad dentro del ecosistema al cual pertenece.

  3. Los microservicios deben ser desplegados de forma independiente. Debido a que cada microservicio tiene su propio código fuente, su propia base de datos, y su propia responsabilidad, es perfectamente posible que cada uno de ellos se pueda desplegar en un container por separado. Un container implica un servidor propio, una maquina virtual propia, inclusive un sistema operativo propio. En el pasado, esto significaba el uso de bastantes recursos y por ende gastos. Sin embargo, hoy en día con los avances de la virtualización este proceso se simplifica. El ejemplo clásico es Docker; un software que crea containers livianos y adaptados para alojar y ejecutar una aplicación de forma independiente.

  4. Los microservicios deben ser organizados entorno a capacidades de negocio. Esto quiere decir que cada microservicio debería diseñarse como un componente que tiene un rol en el negocio. Por ejemplo, pensemos en una aplicación que gestiona matriculas de una escuela, los componentes podrían ser, alumno, curso, horario, sede, entre otros; cada uno de estos componentes tiene su propio rol y responsabilidad en el negocio de “las matriculas”, y por tanto, cada uno de ellos podría desarrollarse como un microservicio.

  5. Los microservicios deberían pertenecer a un pequeño equipo de desarrollo. Debido a que los microservicios son independientes, es posible segmentar un equipo de desarrollo en grupos que les permitan trabajar en cada microservicio de forma autónoma y tomar decisiones de forma rápida.

Conclusión

Como cualquier otra arquitectura los microservicios tienen ventajas y desventajas. En los últimos años hemos visto que grandes empresas han decidido cambiarse a los microservicios, sin embargo, esta decisión trae consigo grandes retos. En el siguiente post exploraremos algunas de las ventajas y desventajas que presentan los microservicios en comparación con una arquitectura tradicional monolítica.


39 vistas0 comentarios

Entradas Recientes

Ver todo