Microservicios
Updated: Jul 8, 2022
La arquitectura de Microservicios, o simplemente Microservicios, es un método distinto para desarrollar software, que ha crecido en popularidad en los últimos años. Para muchos desarrolladores se ha convertido en una forma preferida de crear aplicaciones empresariales. Gracias a su escalabilidad, este método arquitectónico se considera particularmente ideal cuando tiene que habilitar el soporte para una gama de plataformas y dispositivos (que abarcan web, dispositivos móviles, Internet de las cosas y dispositivos portátiles) o simplemente cuando no se está seguro qué tipo de dispositivos se necesitará soportar en el futuro.
Si bien no existe una definición estándar y formal de Microservicios, existen ciertas características que nos ayudan a identificar el estilo. Básicamente, la arquitectura de Microservicios es un método para desarrollar aplicaciones de software estructurado sobre la base de un conjunto de servicios modulares pequeños, levemente acoplados, y de implementación independiente; en el que cada servicio ejecuta un proceso único y se comunica a través de un mecanismo liviano y bien definido para cumplir un objetivo funcional [1].
Uso: Ventajas y Desventajas
Los Microservicios no son una solución mágica, y al implementarlos se expondrá la comunicación, el trabajo en equipo y otros problemas que pueden haber estado previamente implícitos, pero que ahora están forzados a salir a la luz pública. Cómo toda herramienta tiene sus ventajas y desventajas en su uso, así se tiene:
Ventajas
La arquitectura de Microservicio brinda a los desarrolladores la libertad de desarrollar e implementar servicios de manera independiente.
Un Microservicio puede ser desarrollado por un equipo bastante pequeño.
El código para diferentes servicios se puede escribir en diferentes lenguajes (aunque muchos profesionales lo desalientan).
Fácil integración e implementación automática (utilizando herramientas de integración continua de código abierto como Jenkins, Hudson, etc.).
Fácil de entender y modificar para los desarrolladores, por lo tanto, puede ayudar a un nuevo miembro del equipo a ser productivo rápidamente.
Los desarrolladores pueden hacer uso de las últimas tecnologías.
El código está organizado en torno a las necesidades del negocio.
Inicia el contenedor web más rápidamente, por lo que la implementación también es más rápida.
Cuando se requiere un cambio en una determinada parte de la aplicación, solo el servicio relacionado se debe modificar y volver a implementar; no es necesario modificar y volver a implementar toda la aplicación.
Mejor aislamiento de fallas: si un Microservicio falla, el otro continuará funcionando (aunque un área problemática de una aplicación monolítica puede poner en peligro todo el sistema).
Fácil de escalar e integrar con servicios de terceros.
No hay un compromiso a largo plazo con la tecnología.
Desventajas
Debido a la implementación distribuida, las pruebas –testing– pueden volverse complicadas y tediosas.
El aumento en el número de servicios puede generar barreras de información.
La arquitectura ofrece una complejidad adicional ya que los desarrolladores deben mitigar la tolerancia a fallas, la latencia de la red y lidiar con una variedad de formatos de mensajes, así como con el equilibrio de carga.
Al ser un sistema distribuido, puede dar lugar a la duplicación de esfuerzos.
Cuando aumenta la cantidad de servicios, la integración y la administración de productos completos pueden complicarse.
Además de varias complejidades de la arquitectura monolítica, los desarrolladores tienen que lidiar con la complejidad adicional de un sistema distribuido.
Los desarrolladores deben esforzarse más para implementar el mecanismo de comunicación entre los servicios.
El manejo de casos de uso que abarcan más de un servicio sin utilizar transacciones distribuidas no solo es difícil, sino que también requiere comunicación y cooperación entre diferentes equipos.
La arquitectura generalmente resulta en un mayor consumo de memoria.
Particionar la aplicación en Microservicios es en gran medida un arte.
Arquitectura
La arquitectura de los Microservicios [2] es un enfoque para desarrollar una aplicación conformada por un conjunto de pequeños servicios, cada uno ejecutándose en su propio proceso y comunicándose con mecanismos ligeros, a menudo una API de recursos HTTP. Estos servicios se basan en necesidades del negocio y se pueden implementar de forma independiente, mediante una maquinaria de implementación totalmente automatizada. Hay un mínimo de administración centralizada de estos servicios, que puede escribirse en diferentes lenguajes de programación y usar distintas tecnologías de almacenamiento de datos.
Una forma de mejor entender que son los Microservicios, es compararlo con el estilo monolítico: una aplicación monolítica construida como una sola unidad. Las aplicaciones de negocios a menudo están integradas en tres partes principales: una interfaz de usuario del lado del cliente (que consta de páginas HTML y javascript que se ejecutan en un navegador en la máquina del usuario) una base de datos (que consta de muchas tablas insertadas en una administración de bases de datos común, y generalmente relacional), y una aplicación del lado del servidor. La aplicación del lado del servidor manejará las solicitudes HTTP, ejecutará la lógica del dominio, recuperará y actualizará los datos de la base de datos, y seleccionará y completará las vistas HTML que se enviarán al navegador. Esta aplicación del lado del servidor es un monolito, un único ejecutable lógico. Cualquier cambio en el sistema implica crear e implementar una nueva versión de la aplicación del lado del servidor.
Componentes por Medio de Servicios
Un componente es una unidad de software que es reemplazable y actualizable de forma independiente. Las arquitecturas de Microservicios utilizarán bibliotecas (librerías), pero su principal forma de crear un componente de su propio software es dividirse en servicios. Se definen bibliotecas como componentes que están vinculados a un programa y que se llaman mediante llamadas de función en memoria, mientras que los servicios son componentes fuera de proceso que se comunican con un mecanismo como una solicitud de servicio web o una llamada de procedimiento remoto.
Una razón principal para usar los servicios como componentes (en lugar de bibliotecas) es que los servicios se pueden implementar de forma independiente. Si se tiene una aplicación que consta de varias bibliotecas en un solo proceso, un cambio en cualquier componente implica volver a implementar la aplicación completa. Pero si esa aplicación se descompone en múltiples servicios, puede esperarse que muchos cambios en el servicio solo requieran que éste se vuelva a cargar. Eso no es absoluto, en algunos casos se tendrá que reinicializar.
Otra consecuencia de usar servicios como componentes es una interfaz de componentes más explícita. La mayoría de los lenguajes de programación no tienen un buen mecanismo para definir una interfaz pública explícita. A menudo, solo la documentación y la disciplina impiden que los clientes rompan la encapsulación de un componente, lo que lleva a un acoplamiento demasiado apretado entre los componentes. Los servicios hacen que sea más fácil evitar esto utilizando mecanismos de llamada remota explícitos.
Organización en Torno a las Necesidades del Negocio
Cuando se busca dividir una aplicación grande en partes, a menudo la administración se enfoca en la capa de tecnología, lo que excluye a los equipos de User Interface, de lógica del lado del servidor y de base de datos. Cuando los equipos se separan en este sentido, incluso los cambios simples pueden llevar a que un proyecto tome más tiempo y lo mismo con la aprobación de su presupuesto.
El enfoque de Microservicio se basa en descomponer las necesidades funcionales del negocio en muchos servicios, que resuelvan una parte pequeña del todo, de modo que cada una de ellas pueda resolver una función completa, operar independientemente, pero con mecanismos de comunicación precisos entre ellos. De tal forma que este conjunto de servicios cubre la totalidad del requerimiento funcional.
Los equipos para desarrollar Microservicios son multifuncionales, incluida toda la gama de habilidades necesarias para el desarrollo: diseño sistemas, programación, experiencia del usuario, base de datos y gestión de proyectos.
Relación con SOA
Cuando se analizan los Microservicios es común preguntarse sobre como se relacionan con la Arquitectura Orientada a los Servicios (SOA). Esto porque el estilo de los Microservicios es muy similar al de SOA. El problema es que SOA tiene muchas cosas diferentes, y por ello en la práctica Microservicios y SOA son marcos de referencia distintos.
El modelo típico de SOA usualmente tiene una gran dependencia de los buses de datos EBS a diferencia los Microservicios. SOA se focaliza en la programación imperativa, por su parte Microservicios ocupa el estilo de programación reactiva. Por otra parte, SOA preferentemente usa una base de datos externa, mientras los Microservicios suelen ocupar las bases de datos NoSQL o micro-SQL (las que se pueden conectar a las bases de datos convencionales). Pero, la real diferencia entre SOA y Microservicios tiene que ver con los métodos que las arquitecturas utilizan para lograr la integración del conjunto de servicios.
Cómo se Construyen
Cada Microservicio se puede implementar en cualquier lenguaje de programación [3] y puede utilizar diferentes infraestructuras. Las tecnologías avanzadas son el medio de comunicación de los Microservicios (síncrono, asincrónico, etc.) y el protocolo que utilizan (REST, mensajería, etc.). Basado en los requisitos de servicio, se debe elegir el mecanismo de comunicación y su protocolo. El componente arquitectónico se puede categorizar en:
Balanceador de Carga.
Service Discovery
Base de Datos / Cache.
Para más información sobre las herramientas para la programación de los Microservicios y cómo las están utilizando las empresas está el sitio Stackshare.
Capacitación
Para quienes necesiten iniciarse en la programación de los Microservicios están disponible muchos cursos la red, a modo de ejemplo incluyo los links siguientes:
Referencias
[1] https://smartbear.com/learn/api-design/what-are-microservices/
[2] www.martinfowler.com/articles/microservices.html#footnote-etymology
[3] https://dzone.com/articles/tools-and-techniques-to-build-microservices