Simplifica Tu Arquitectura de Microservicios con Una API de Datos

¿ Haz encontrado desafíos en la forma de administrar datos en una arquitectura de microservicios ? En este Post, examinaremos los enfoques tradicionales y presentamos la puerta de enlace API de datos (a veces también conocida como “puerta de enlace de datos”), un nuevo tipo de infraestructura de datos. Exploraremos las características de una puerta de enlace API de datos, porque deberías implementarla y como aplicarla a tu arquitectura.

Antes de continuar, te invito a escuchar el Podcast: “Porque Debes Acostumbrarte A Resolver Los Problemas De Código Por Tu Cuenta” y “Ventajas y Desventajas de Usar 2 o Más Monitores Para un Desarrollador” (Anchor Podcast): 

Spotify:	Sound Cloud:	Apple Podcasts	Anchor Podcasts

Bien ahora continuemos con el Post: Simplifica Tu Arquitectura de Microservicios con Una API de Datos.

El Patrón de Servicio de Datos Tradicional

Primero, consideremos cómo se administran los datos en las arquitecturas de microservicios. Un patrón común es una capa de servicios de datos que realizan operaciones CRUD (Crear, Leer, Actualizar y Eliminar). Por ejemplo, considera una aplicación de reserva de hotel que se muestra en la siguiente imagen:

Esta arquitectura de microservicios incluye una capa de servicios de datos que administran tipos de datos específicos, incluidos hoteles, tarifas, inventario, reservas e invitados, y una capa de servicios comerciales que implementan procesos específicos, como compras y reserva de reservas. Los servicios empresariales proporcionan una interfaz principal para las aplicaciones web y móviles y delegan el almacenamiento y la recuperación de datos a los servicios de datos. Los servicios de datos son responsables de realizar operaciones CRUD en una base de datos subyacente.

Si bien existen muchas formas de integrar y orquestar las interacciones entre estos servicios, el patrón básico de separar los servicios responsables de los datos y la lógica comercial ha existido desde los primeros días de la arquitectura orientada a servicios (SOA).

Identificación, Diseño e Implementación de Servicios de Datos

El enfoque típico para desarrollar estos microservicios ha incluido pasos como los siguientes:

Identificar servicios para administrar tipos de datos específicos en el dominio usando una técnica como el diseño dirigido por el dominio. Para obtener más información sobre la interacción entre el diseño basado en dominios, la identificación de servicios y el modelado de datos, consulta el Capítulo 7 de el libro Cassandra, The Definitive Guide : 3rd Edition .

Diseño de servicios que incluyen API y esquemas para administrar los tipos de datos asignados. Cada servicio individual es el propietario principal de un tipo de datos específico y es responsable del almacenamiento de datos, la recuperación y la posible mensajería o transmisión. A continuación, ampliaremos las implicaciones de esto para la selección de bases de datos.

Implementación de servicios utilizando un lenguaje y frameworks seleccionados. En el mundo de Java, los frameworks como Spring Boot facilitan la creación de servicios con un servidor HTTP integrado que luego se empaqueta en máquinas virtuales o contenedores. Quarkus es un framework más reciente que puede crear, probar y contener servicios en un solo flujo de trabajo de CI.

Servicios de Datos y Persistencia Políglota

Muchas de las primeras arquitecturas SOA incluían servicios que interactuaban con un único esquema de base de datos relacional heredado. Una consecuencia desafortunada de esto fue la tendencia a “integrar por base de datos”, donde los servicios podían leer y escribir libremente en varias tablas. Esta falta de propiedad sólida a menudo generaba problemas de integridad de datos que eran difíciles de depurar.

A medida que comenzó el movimiento hacia arquitecturas de microservicios a gran escala en la nube en la década de 2010, los innovadores a gran escala, incluido Netflix, abogaron firmemente por servicios independientes que administraran sus propios tipos de datos. Una consecuencia de esto fue que los servicios de datos individuales tenían libertad para seleccionar sus propias bases de datos, un patrón conocido como persistencia políglota. En la siguiente imagen se muestra un ejemplo de cómo se vería esto en nuestra aplicación hotelera hipotética.

En esta arquitectura, los datos de tamaño modesto que cambian con menos frecuencia, como las descripciones de hoteles, pueden ser una opción natural para una base de datos de documentos o una base de datos relacional tradicional. Los datos con alto volumen o alto tráfico de lectura/escritura, como tarifas, inventario y reservas, pueden usar una solución basada en NoSQL en clúster para escalar de manera efectiva. Otros servicios de datos pueden ser una fachada para una API de terceros, como la información de invitados procedente de un sistema de gestión de relaciones con los clientes (CRM).

Reemplazo de Servicios de Datos Con Una Puerta de Enlace API de Datos

Al crear múltiples servicios de datos, los equipos de desarrollo a menudo descubren que las implementaciones son muy similares, casi un código repetitivo, debido a su responsabilidad enfocada de ejecutar operaciones CRUD simples sobre un backend de base de datos. Reconociendo esta duplicación de esfuerzos, muchas organizaciones han comenzado a adoptar puertas de enlace API de datos como una alternativa para mantener una capa de servicios de datos en contenedores.

Una puerta de enlace de API de datos es una pieza de infraestructura de software que brinda acceso a datos a través de API de varios estilos, incluidos REST, gRPC y otros. La puerta de enlace abstrae los detalles del almacenamiento y la recuperación de datos utilizando uno o más almacenes persistentes. Esto permite a los desarrolladores de aplicaciones centrarse en escribir servicios comerciales que accedan a los datos a través de API fáciles de usar en lugar de tener que aprender las complejidades del lenguaje de consulta de una base de datos.

La siguiente imagen muestra un ejemplo de cómo se podría aplicar una puerta de enlace de este tipo al ejemplo de la aplicación del hotel. La puerta de enlace API de datos asume la responsabilidad de administrar la persistencia de datos para hoteles, tarifas, inventario y otros tipos de datos, eliminando la necesidad de una capa completa de servicios de datos.

Comparación de Estilos de API

Las puertas de enlace de API de datos brindan a los desarrolladores la libertad de acceder a los tipos de datos a través de la API que tienen más sentido para sus aplicaciones y servicios de cliente. La siguiente imagen compara algunos de los estilos de API más comunes en términos de cómo estructuran los datos y sus características de rendimiento.

Los estilos de API como gRPC brindan representaciones de datos más estructurados que pueden conducir a un rendimiento más óptimo. Las API GraphQL y REST brindan más flexibilidad en la forma en que se representan los datos a costa de una latencia adicional. La máxima flexibilidad la proporcionan las API de estilo de documento que pueden almacenar y buscar JSON en cualquier formato que elija el cliente, a costa de un rendimiento potencialmente más bajo para consultas más complejas.

Proyectos de Puerta de Enlace de API de Datos

Muchas organizaciones han creado sus propias puertas de enlace de API de datos y algunas de ellas se encuentran en diversas etapas de lanzamiento como proyectos de código abierto. Un ejemplo es Stargate , un proyecto de código abierto que proporciona múltiples estilos de API como una capa de proxy sin estado sobre Apache Cassandra. Los marcos GraphQL, como Apollo Supergraph Platform o Netlify’s OneGraph, también podrían considerarse una adaptación específica del patrón de puerta de enlace de API de datos en el sentido de que agregan datos de múltiples API y backends de persistencia.

Implementación de Una Puerta de Enlace API de Datos

La implementación de una puerta de enlace en contenedores incluye potencialmente varios servicios de API y almacenes de datos de respaldo. Veamos Stargate como ejemplo de una puerta de enlace de API de datos que se implementa como una aplicación de microservicios. La siguiente imagen muestra un ejemplo de implementación de Stargate en Kubernetes.

Un clúster de Cassandra se implementa mediante un StatefulSet, que permite que los pods se vinculen a PersistentVolumes para lograr una alta disponibilidad de los datos almacenados. Los nodos coordinadores de Stargate sin estado y los servicios de API, como documentos, gRPC y REST, se administran en implementaciones de Kubernetes para que cada microservicio pueda escalar de forma independiente. Los servicios de Kubernetes proporcionan equilibrio de carga en varias instancias de microservicios.

Conclusión

La puerta de enlace API de datos es un nuevo tipo de infraestructura de datos que puede ayudar a eliminar capas de microservicios de estilo CRUD que debe desarrollar y mantener. Si bien existen múltiples estilos de puerta de enlace, tienen un conjunto común de características que benefician tanto a los desarrolladores como a los operadores. Las puertas de enlace de API de datos permiten la productividad del desarrollador al proporcionar una variedad de estilos de API en una única base de datos de soporte. Desde una perspectiva de operaciones, las puertas de enlace de la API de datos y sus bases de datos de apoyo se pueden ejecutar en contenedores junto con otras aplicaciones para simplificar su proceso de implementación general. En resumen, la adopción de una puerta de enlace API de datos es una excelente manera de reducir los costos de desarrollo y mantenimiento de las arquitecturas de microservicios.

Nota(s)

• No olvides que debemos usar la Tecnología para hacer cosas Buenas por el Mundo. 

Síguenos en las Redes Sociales para que no te pierdas nuestros próximos contenidos.