Migrar a una arquitectura de microservicios, sus beneficios y componentes necesarios

y en día podemos ver como el estilo de arquitectura de Microservicios se vuelve una opción predominante en las áreas de T.I de las empresas, ya que implementar una solución con Microservicios trae bastantes beneficios como: compatibilidad con infraestructuras Cloud, facilidad en escalabilidad horizontal, uso de múltiples tecnologías, manejo de recursos por funcionalidad, y muchos más.

SOA vs Microservicios

SOA es un término conocido en nuestras organizaciones, es una arquitectura que nos lleva de tener aplicaciones monolíticas, a tener funcionalidades específicas, reutilizables, separadas por capas, y que finalmente terminan siendo servicios web, que exponemos internamente en nuestra organización o externamente a nuestros partners o clientes.

Microservicios lo podemos ver como una evolución de SOA, donde tenemos funcionalidades de negocio o utilitarias específicas, pero en este caso más granulares y con una interfaz común, para que se comuniquen entre si (API REST). También en Microservicios, tenemos estas funcionalidades de manera autónoma e independiente, es decir, que cualquier cambio en alguno de estos componentes no debe afectar a los demás (funcionan, escalan y fallan por separado), a diferencia de SOA, que a pesar de que estamos separando funcionalidades en servicios web, estos se encuentran en un componente monolítico (ESB, Servidor web), compartiendo recursos dentro de un mismo paquete.

Con lo mencionado anteriormente, no queremos decir que para hacer Microservicios debemos tener SOA, ya que podemos adaptar Microservicios con algún proyecto o aplicación nueva en nuestra Organización, o incluso tomar alguna aplicación Monolítica para pasarla gradualmente a esta arquitectura.

¿Cómo hacer Microservicios?

Cuando tenemos un nuevo proyecto (aplicación, Backend, api), o queremos migrar una aplicación monolítica a una arquitectura de microservicios, debemos tener en cuenta los siguiente:

• Lo que tradicionalmente llamábamos capa de negocio (donde procesamos una lógica de negocio), debemos separarla en pequeños servicios, que cumplan con una función o funciones específicas, teniendo en cuenta lo siguiente:
• • • • • • Tener servicios por cada entidad, por ejemplo, en un proceso de ventas tener por separado servicios de clientes, facturación, productos, inventario, etc.
          • Dividir en grupos de funcionalidades de cada entidad, continuando con el ejemplo anterior, podemos tener por cada entidad un grupo de funcionalidades transaccionales, y otras de consultas (reportes, consultas generales), cada grupo de estos sería un servicio por separado.
          • Para cada entidad o grupo de funcionalidades de cada entidad, debemos tener servicios por separado de acceso a datos, y cada uno de estos, debe tener su conexión independiente (usuario, password, esquema).
          • Debemos tener también, servicios transversales o utilitarios, que sean utilizados por los demás servicios, por ejemplo, logs, envío de correos, acceso a servicios externos, seguridad, etc.

Finalmente, estos puntos mencionados, no son una camisa de fuerza para diseñar “mi arquitectura” de microservicios, pero sí tenemos en cuenta estos principios o lineamientos, la posibilidad de éxito en nuestros proyectos es mayor, y también permite que nuestra arquitectura se adapte más fácil a los cambios generados por el negocio.

¿Qué componentes debo tener para implementar Microservicios?

Desde hace varios años se ha introducido el término “contenedor” dentro de las áreas de infraestructura y desarrollo de las Organizaciones. Estos contenedores son una evolución de las infraestructuras tradicionales, donde primero teníamos una o varias aplicaciones desplegadas en un servidor completo y un gran desperdicio de recursos. Luego pasamos al uso de máquinas virtuales, donde teníamos un control mejorado de recursos y una mejor administración de nuestros servidores, pero finalmente tenemos aplicaciones con recursos compartidos o monolíticas, y también el gran reto para escalar “mis aplicaciones” (en caso de picos o demandas altas).

Ahora, en esta evolución de infraestructuras para nuestros servicios y aplicaciones, tenemos los contenedores, donde un contenedor es un componente mucho más ligero y rápido que una máquina virtual, ya que este contenedor no cuenta con un sistema operativo completo, por lo que usa únicamente las funcionalidades necesarias del kernel para encapsular un sistema, y dentro de este contenedor tenemos las librerías necesarias para correr una aplicación.[CS1]

Cada contenedor corre de forma independiente y aislada de otros contenedores, los cuales son portables, escalables, de uso mínimo de recursos e inicio rápido.

Con esta introducción vamos a ver algunos componentes que podemos tener dentro de “mi arquitectura” de microservicios: 

1. El primer componente que debemos tener en cuenta son los contenedores, ya que con estos podemos tener los servicios (en lenguajes y tecnologías diferentes) funcionando y fallando de manera independiente, aislada y autónoma.
2. Al tener muchos contenedores (microservicios), la administración de estos, se nos puede convertir en un dolor de cabeza, ya que en este mundo, hablamos de cientos de servicios y cada servicio puede tener varios contenedores (para tener más recursos y capacidad de carga), esto manualmente se nos transforma en una tarea tediosa ya que toca monitorearlos cuando se caen, escalarlos (hacia arriba o hacia abajo),  además vamos a tener muchas urls por distintos puertos, que debemos administrar adecuadamente.

Para esto debemos tener una plataforma de administración de contenedores, la cual nos permite tener los siguientes beneficios:

Capacidad de eliminar un contenedor y volverlo a crear, en caso de algún fallo. 

• Escalar “mi servicio” en varios contenedores, según la capacidad.
• Una única URL, para “mi servicio”, así éste cuente con varios contenedores.
• Un punto único de acceso, administración y monitoreo de mis servicios.

Un componente bastante útil, pero opcional, es contar con un API Gateway, ya que juntando este al Orquestador de Contenedores, puedo tener beneficios adicionales como:

Un punto centralizado de gobierno de mis servicios (creación, publicación, ciclo de vida, búsqueda de funcionalidades).

1. Seguridad, políticas de consumo y acceso (interno o externo) para cada servicio, sin necesidad de desarrollos adicionales y personalizados
2. Los mejores estándares de seguridad (OAUTH, JWT), que podemos utilizar junto a una herramienta “Identity Management”, para robustecer la arquitectura.
3. Estadísticas de uso y métricas de cada servicio.

Otros componentes pueden complementar aún más la arquitectura, incluyendo herramientas de monitoreo y logs que nos permitan un control de la infraestructura y tener métricas de uso, también podemos tener herramientas de CI/CD (GIT, Jenkins, Nexus, Sonar) que nos permitan tener un modelo Devops que le de valor y agilidad al negocio, entre otros.

Beneficios de los Microservicios

• Valor al negocio: los microservicios nos permiten ser más ágiles en la salida a producción de las aplicaciones, ya que podemos cambiar o adaptar nuevas funcionalidades rápidamente, sin impactar el producto en general, reduciendo tiempo en desarrollo, QA e infraestructura.

También, con una herramienta de API Gateway, como veíamos en el punto anterior, podemos tener métricas de uso por consumidor, y así monetizar las funcionalidades o servicios. Teniendo modelos de cobro por uso, como lo hacen las API de las plataformas de pago, turismo, Google, Amazon, etc.

• Múltiples lenguajes o tecnologías: Al comunicarse “mis servicios” a través de una interfaz común (API REST), cada servicio u aplicación, puede estar desarrollado en un lenguaje distinto, con plataformas distintas que corren dentro de cada contenedor autónomo e independiente.
• Escalabilidad Horizontal: El mundo de los contenedores nos permite de una manera sencilla escalar “mis servicios” de forma independiente, dependiendo de la capacidad de cada uno de ellos, sin generar impacto en otros contenedores, que tienen otros servicios.
• Integración con DevOps: El mundo de microservicios va de la mano con la cultura DevOps, podemos tener mayor agilidad de negocio, al reducir tiempos de despliegue y pruebas de QA, ya que manejamos el ciclo de vida de cada servicio de manera independiente.

Espero que este artículo sea de gran utilidad, a la hora de abordar en este gran mundo de Microservicios, ya que son más las ventajas, que las desventajas que pueda traer la implementación de esta arquitectura en las empresas, eso sí, haciéndolo de la manera correcta, siguiendo los lineamientos, patrones y principios que nos ofrece este estilo de arquitectura.

Como conclusión tenemos un estilo de arquitectura que trae nuevos conceptos, y herramientas, que se adapta a la perfección con la cultura DevOps, y es totalmente compatible con metodologías ágiles de desarrollo, ya que al tener componentes independientes y granulares, podemos contar con nuevos elementos y versiones en un corto tiempo y con un impacto muy bajo sobre el resto de proyecto.

En BMind contamos con servicios especializados en la “Integración Ágil” de aplicaciones y además contamos con prácticas para apoyarlo en actividades como:

• Formulación y diseño de políticas, lineamientos y procedimientos para selección y uso de Plataforma de contenedores.
• Implementación de arquitecturas de microservicios a la medida de cada necesidad.
• Servicios de Entrenamiento, Soporte y Soluciones de contenerización a la medida.