Cuándo y cómo debería usar una arquitectura de microservicios

El arquitectura de microservicios está recibiendo mucha atención últimamente, y esto no es una coincidencia. Hay algunas grandes compañías como Netflix y Amazon que han explicado cómo están usando un arquitectura de microservicios para poder escalar sus servicios y asegurarse de que puedan proporcionarlos de forma continua y sin interrupciones.

Una arquitectura de microservicios tiene más sentido en comparación con el diseño de aplicaciones monolíticas.

En el diseño arquitectónico monolítico, creamos una aplicación enorme y pesada con todos los módulos estrechamente acoplados dentro de un solo ejecutable que de forma general se implementa en un servidor web o de aplicaciones. A pesar de esto, este diseño arquitectónico tiene algunos inconvenientes que han permitido el uso del arquitectura de microservicios hacerse popular:

• No hay actualizaciones fáciles y frecuentes.

• Problemas de distribución continua.

• Difícil de administrar equipo y proyecto.

• Rendimiento y escalabilidad costosos.

• Falta de diversidad tecnológica.

• No es fácil reemplazar los componentes.

¿Qué es una arquitectura de microservicios?

Un estilo de arquitectura de microservicios logra una configuración donde los componentes de la aplicación son aplicaciones independientes. Estos componentes independientes de la aplicación se comunican entre sí a través de RMI (Invocación de método remoto), Restful Web Services o Push Messaging.

Al diseñar sistemas en una arquitectura de microservicios, debemos identificar los componentes independientes. Estos componentes serán miniaplicaciones, que se desarrollarán de forma separada. Seguirán su propio ciclo de desarrollo y despliegue.

En una configuración general podemos tener escenarios en los que necesitamos datos de varios componentes para una sola solicitud. Idealmente, tendremos una puerta de link API o un controlador frontal que agregue los datos de estos componentes y los devuelva.

Además debemos tener comunicación entre componentes. Los componentes pueden comunicarse por medio de API REST o mensajería o RMI (invocación de método remoto).

Las características de una aplicación basada en arquitectura de microservicios son las siguientes:

• Servicio habilitado, ejecución independiente de componentes.

• Ejecución independiente de componentes en torno a algunas capacidades comerciales.

• Mentalidad de producto en lugar de proyecto.

• Componentes inteligentes que usan canales de comunicación simples como el protocolo RESTish simple o la cola de mensajes ligeros.

• Estándares descentralizados. Cada componente independiente puede usar su propio estándar exclusivo para el desarrollo y la implementación.

• Administración de datos descentralizada. Cada componente individual tiene su propio almacenamiento de datos.

• Administración automatizada de la infraestructura. Para la implementación de componentes independientes, debemos confiar en la administración de infraestructura automatizada para reducir la complejidad.

• Diseño de la aplicación teniendo en cuenta posibles fallos. Hay varias partes móviles independientes en las aplicaciones. En caso de que el receptor no obtenga respuesta, debe gestionarse correctamente.

• Diseño evolutivo para obtener el mejor sistema de descomposición factible, que puede ser reemplazado y actualizado sin afectar su entorno.

Cuándo utilizar una arquitectura de microservicios

Deberíamos usar una arquitectura de microservicios para cualquier producto o proyecto con estos dos enfoques:

• Solo monolítico o con un primer enfoque monolítico. Regularmente, cuando una aplicación monolítica tiene éxito o necesita ayuda para escalar y mejorar el rendimiento, podemos decantarse por una arquitectura de microservicios de dos formas:
• Amplíe los componentes modulares bien diseñados de la aplicación monolítica.
• Cree la aplicación de microservicios desde cero y volque la aplicación monolítica existente en ella.
• Un primer enfoque de microservicios. Debemos decantarse por el primer enfoque de microservicios cuando:
• La modularidad y la descentralización son un aspecto importante desde el inicio de cualquier proyecto.
• Anticipamos que la aplicación tendrá un gran volumen de transacciones o tráfico.
• Tenemos preferencia por los beneficios a largo plazo sobre los a corto plazo.
• Contamos con el conjunto de personas adecuado para diseñar, desarrollar e poner en práctica aplicaciones rápidamente, especialmente durante la etapa inicial.
• Estamos comprometidos con el uso de herramientas y tecnologías de vanguardia.

Cómo utilizar una arquitectura de microservicios

Desafortunadamente, La mayor parte de la información disponible sobre la arquitectura de microservicios explica por qué deben usarse, pero no cómo.. Es bueno saber que los microservicios podrían revolucionar el diseño, la implementación y el funcionamiento de las aplicaciones. Pero, ¿cómo se construye exactamente un único microservicio? Debe comprender los componentes fundamentales de un microservicio si desea que la salida funcione correctamente y no termine luciendo como la misma aplicación monolítica con una nueva capa de pintura.

Estos son los Cinco ítems que necesitará un microservicio antes de que pueda usarse en una arquitectura de aplicación distribuida:

1. Funcionalidad con alcance adecuado. El primer elemento de un microservicio es establecer qué debe hacer. Una forma de establecer el alcance adecuado es dividir los servicios en función de la funcionalidad lógica. Otro enfoque de alcance es reflejar la estructura de la organización de desarrollo. Un tercer enfoque es minimizar un servicio a la cantidad de código que el equipo podría reintroducir en un período de dos semanas.
2. Prepara una API. Una vez que dividimos una aplicación en múltiples servicios cooperativos, ¿cómo deberían comunicarse esos servicios entre sí? Regularmente, esto se hace con llamadas a la API del servicio web REST, aún cuando además se pueden usar otros mecanismos de transporte. Una buena idea es evitar saltar a la codificación API de inmediato. En cambio, es mejor trabajar en papel o pizarra para establecer qué debe exponer un servicio específico para funcionar correctamente.
3. La administración del tráfico. Desde la perspectiva del servicio de llamadas, siempre debe hacer un seguimiento de sus llamadas y estar listo para terminar si la solución tarda demasiado. Desde la perspectiva del servicio llamado, el diseño de la API debe incluir la capacidad de enviar una respuesta que indique sobrecarga. Los servicios además deben ser capaces de generar y borrar nuevas instancias de servicio según sea necesario para adaptarse a las variaciones en la carga de tráfico.
4. Descarga de datos. Tener la necesidad de un funcionamiento continuo es muy distinto de lo que necesitan las aplicaciones tradicionales, que a menudo dejan de funcionar si falla la infraestructura subyacente. Para garantizar que los usuarios puedan seguir trabajando cuando falla una instancia, los datos específicos del usuario se pueden migrar fuera de las instancias de servicio a un sistema de almacenamiento redundante compartido alcanzable desde todas las instancias de servicio. Otro enfoque para descargar el almacenamiento es insertar un recurso compartido de caché basado en memoria entre un servicio dado y el almacenamiento asociado con ese servicio.
5. Vigilancia. El sistema de monitoreo de una aplicación basada en una arquitectura de microservicios debe permitir el cambio continuo de recursos, poder capturar datos de monitoreo en una ubicación central y mostrar información que refleje la naturaleza cambiante de las aplicaciones de microservicios.