El valor de la gestión de datos

Cuándo y cómo deberías utilizar una arquitectura de microservicios

Posted on Thu, Sep 7, 2017

La arquitectura de microservicios está recibiendo mucha atención últimamente, y esto no es una casualidad.. Hay algunas grandes empresas como Netflix y Amazon que han explicado cómo están utilizando una arquitectura de microservicios para poder escalar sus servicios y garantizar que pueden prestarlos de forma continua y sin interrupciones.

arquitectura de microservicios

Una arquitectura de microservicios tiene más sentido cuando la comparamos con el diseño de aplicaciones monolíticas.

 

Descárgate aquí la guía

 

En el diseño arquitectónico monolítico creamos una enorme y pesada aplicación con todos los módulos estrechamente acoplados dentro de un solo ejecutable que se despliega típicamente en un servidor web o de aplicaciones. Sin embargo, este diseño arquitectónico tiene algunos inconvenientes que han permitido que el uso de la arquitectura de microservicios adquiera popularidad:

  • No hay actualizaciones frecuentes y fáciles.
  • Problemas para la distribución continua.
  • Equipo y proyecto difícil de gestionar.
  • Escalabilidad y rendimiento 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 obtiene una configuración donde los componentes de la aplicación son aplicaciones independientes. Estos componentes independientes de la aplicación se hablan entre sí utilizando RMI (Remote Method Invocation), Restful Web Services o Push Messaging.

Al diseñar sistemas en una arquitectura de microservicios, deberíamos identificar los componentes independientes. Estos componentes serán mini aplicaciones, que se desarrollarán por separado. Seguirán su propio ciclo de desarrollo y despliegue.

En una configuración general podemos tener escenarios donde necesitamos datos de varios componentes para una sola solicitud. Idealmente, tendremos una pasarela API o controlador frontal que agrega los datos de estos componentes y los devuelve.

También debemos tener una comunicación entre componentes. Los componentes pueden comunicarse a través de las API de REST o Messaging o RMI (Remote Method Invocation).

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 de negocio.
  • Mentalidad de producto en lugar de proyecto.
  • Componentes inteligentes que utilizan canales de comunicación simples como el simple protocolo RESTish o la cola de mensajes ligeros.
  • Estándares descentralizados. Cada componente independiente puede utilizar su estándar exclusivo para desarrollo y despliegue.
  • Gestión descentralizada de datos. Cada componente individual tiene su propio almacenamiento de datos.
  • Gestión automatizada de la infraestructura. Para el despliegue de componentes independientes, necesitamos confiar en la gestión automatizada de la infraestructura para así reducir la complejidad.
  • Diseño de aplicación teniendo en cuenta posibles fallos. Hay varias partes móviles independientes en las aplicaciones. En caso de que el receptor no obtenga una respuesta, debe gestionarse correctamente.
  • Diseño evolutivo para obtener el mejor sistema de descomposición posible, que pueda ser sustituido y actualizado sin afectar a su alrededor.

 

Cuando utilizar una arquitectura de microservicios

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

  • Únicamente monolítico o con un primer enfoque monolítico. Normalmente, cuando una aplicación monolítica tiene éxito o necesita ayuda para escalar y mejorar el rendimiento, podemos optar por una arquitectura de microservicios de dos maneras:
    • Extender los componentes modulares bien diseñados de la aplicación monolítica.
    • Crear la aplicación de microservicios desde cero y volcar en ella la aplicación monolítica existente.
  • Un primer enfoque de microservicios. Debemos optar por la primera aproximación a los microservicios cuando:
    • La modularidad y la descentralización son un aspecto importante desde el inicio de cualquier proyecto.
    • Prevemos que la aplicación tendrá un alto volumen de transacciones o de tráfico.
    • Tenemos preferencia por beneficios a largo plazo en comparación con los de corto plazo.
    • Disponemos de un conjunto adecuado de personas para diseñar, desarrollar e implementar aplicaciones rápidamente, sobre todo durante la fase inicial.
    • Tenemos el compromiso de utilizar herramientas y tecnologías de vanguardia.

Cómo utilizar una arquitectura de microservicios

Desafortunadamente, la mayor parte de la información disponible sobre arquitectura de microservicios explica por qué deberían usarse, pero no cómo hacerlo. Es bueno saber que los microservicios podrían revolucionar el diseño, la implementación y la operación de las aplicaciones. ¿Pero exactamente cómo construyes un microservicio individual? Es necesario comprender los componentes fundamentales de un microservicio si deseas que el resultado funcione correctamente y no acabe pareciendo la misma aplicación monolítica antigua con una nueva capa de pintura.

Estos son los cinco elementos que un microservicio necesitará antes de que pueda utilizarse en una arquitectura de aplicación distribuida:

  1. Funcionalidad con un alcance adecuado. El primer elemento de un microservicio es definir lo que debe hacer. Una forma de definir el ámbito adecuado es particionar los servicios a lo largo de las líneas de 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 podría ser reintroducido por el equipo en un período de dos semanas.
  2. Preparación de una API. Una vez que descomponemos una aplicación en múltiples servicios que cooperan, ¿cómo deben hablar esos servicios entre sí? Normalmente, esto se hace con llamadas a API de servicios web REST, aunque también pueden utilizar otros mecanismos de transporte. Una buena idea es evitar saltar a la codificación de la API de forma inmediata. En su lugar es mejor hacer algún trabajo en papel o pizarra para definir lo que un servicio específico debe exponer para funcionar correctamente.
  3. Gestión del tráfico. Desde la perspectiva del servicio de llamada, siempre debe realizar un seguimiento de sus llamadas y estar preparado para terminar si la respuesta toma demasiado tiempo. Desde la perspectiva del servicio llamado, el diseño de API debe incluir la posibilidad de enviar una respuesta que indique sobrecarga. Los servicios deben ser capaces también de generar y matar nuevas instancias de servicio según sea necesario para acomodar variaciones en la carga de tráfico.
  4. Descarga de datos. Tener necesidad de una operación continua es muy diferente de lo que necesitan las aplicaciones tradicionales, que a menudo dejan de funcionar si falla la infraestructura subyacente. Para asegurarse de que los usuarios pueden seguir trabajando cuando falla una instancia, se pueden migrar datos específicos del usuario fuera de las instancias de servicio a un sistema compartido de almacenamiento redundante accesible desde todas las instancias de servicio. Otro enfoque de descarga de almacenamiento es insertar un sistema compartido de caché basado en memoria entre un servicio dado y el almacenamiento asociado con ese servicio.
  5. Monitorización. El sistema de monitorización de una aplicación basada en una arquitectura de microservicios debe permitir el cambio continuo de recursos, ser capaz de capturar datos de monitorización en una ubicación central y mostrar información que refleje la naturaleza con frecuencia cambiante de las aplicaciones de microservicios.

 

New Call-to-action

Topics: SOA