Sergej Khackimullin - Fotolia
Cómo combatir la complejidad en los microservicios con la gestión de datos
Los arquitectos que cambian de un monolito a microservicios deben considerar un componente crítico: los datos. Aprenda cómo los microservicios afectan la administración de datos y descubra herramientas que pueden ayudar.
A medida que las organizaciones mueven datos de arquitecturas monolíticas hacia microservicios y contenedores, las prácticas tradicionales de administración de datos pueden estar en riesgo. Para mantener la integridad de los datos, los desarrolladores y arquitectos deben reestructurar sus prácticas de administración de datos de microservicios en consecuencia.
"Con respecto a la contenerización, los arquitectos deben ser conscientes de que los contenedores no están diseñados para ser persistentes, [lo cual es] un requisito clave para cualquier carga de trabajo con uso intensivo de datos", dijo Matt Aslett, director de investigación de plataformas de datos y análisis en 451 Research.
Los contenedores estándar de Docker incluyen volúmenes de datos que están vinculados a un servidor individual. Esto significa que, si un contenedor falla o se mueve de un servidor a otro, su conexión con el volumen de datos se pierde, dijo. Sin embargo, los contenedores de datos se pueden usar para conservar los datos en un contenedor extra para la aplicación, mientras que los complementos de volumen de Docker permiten a los usuarios aprovechar los sistemas de almacenamiento de terceros para crear, eliminar, montar y desmontar volúmenes de datos, agregó.
Dos estrategias de datos esenciales
Edwin Yuen, analista de Enterprise Strategy Group, está de acuerdo en que la gestión de datos es una consideración importante cuando se trata de microservicios y sistemas distribuidos. Sin embargo, hay estrategias que las organizaciones pueden usar para evitar que los datos de microservicios se vuelvan demasiado dispersos para ser administrados, dijo Yuen.
Primero, dijo Yuen, los arquitectos deben lidiar con la consolidación de datos.
"En el mundo monolítico, esto era problemático debido a la centralización de los datos en un único centro de datos, que podría tener problemas de acceso a datos, rendimiento y de copia de seguridad y recuperación", dijo Yuen. Con los servicios y el almacenamiento en la nube distribuidos, ahora es posible usar nubes de hiperescala para proporcionar el back-end de datos para múltiples aplicaciones y usar la escala y la replicación de datos dentro de las nubes de hiperescala para administrarlas mejor, explicó.
"La ruptura de la gestión de datos tradicional es ir más allá de pensar en los datos como un único conjunto o ubicación y pensar en ello como un servicio de datos que puede ser independiente de la ubicación", dijo Yuen.
Un segundo enfoque, más avanzado, es analizar las aplicaciones y los servicios y determinar si necesitan acceso al conjunto de datos actual o primario, dijo Yuen. Si la aplicación no requiere los datos actualizados en tiempo real, no está relacionada con la producción o podría utilizar una copia de los datos, se puede usar el concepto de gestión y habilitación de datos o administración de datos de copia.
"Estos servicios pueden obtener una copia del conjunto de datos del almacenamiento primario o secundario y permitir que la aplicación o los servicios funcionen a partir de esa copia de datos", dijo.
Los clones de datos también se pueden poner disponibles, agregó Yuen. Los desarrolladores podrían utilizar estas copias de datos para fines de minería de datos, ventas o demostración, pero también pueden derivarse del almacén de datos primario.
"Las copias de datos se rastrean y administran, pero gran parte de la administración de datos tradicional se reduce, lo que permite una mayor distribución de los datos sin los requisitos de administración distribuidos", dijo Yuen.
La importancia de la planificación de datos
Randy Shoup, ex vicepresidente de ingeniería de Stitch Fix, un minorista de ropa en línea, adoptó un enfoque similar al de Yuen. Históricamente, Stitch Fix tenía una base de datos monolítica, pero la compañía se está moviendo hacia una arquitectura basada en servicios, dijo Shoup.
"Hemos estado avanzando lentamente hacia los servicios, y no hemos terminado. Pero esa es la evolución normal de cualquier compañía", dijo Shoup, citando las experiencias de Amazon, eBay y Twitter. "Cada uno de ellos comenzó con un monolito retrospectivamente feo porque inicialmente no podían darse el lujo de construir para lo que serían años en el futuro".
A pesar de que los datos de microservicios a menudo se distribuyen ampliamente, la planificación es la clave, dijo Shoup, quien ahora es vicepresidente de ingeniería en WeWork, un proveedor de espacios de oficina compartidos.
"Tengo muchos microservicios en mi empresa que necesitan saber sobre el cliente, pero tengo un lugar que posee los datos del cliente", dijo. Por ejemplo, Shoup explicó que el servicio de satisfacción (fulfillment) en Stitch Fix necesita la dirección del cliente, y el equipo de atención al cliente también necesita parte de esa información. Para Shoup, la clave es tener un servicio que actúe como un sistema de registro para el cliente.
"El servicio al cliente es propietario del cliente y tiene la representación canónica en su sistema de registro, mientras que cualquier otro lugar que pueda tener esa información se considera un caché no autoritario y de solo lectura", dijo. Un servicio de satisfacción puede retener la información, pero aún es solo caché: solo lectura y no autoritario. Si otra entidad solicita la dirección del cliente, es como el sistema de nombres de dominio, que es un caché no autoritario de información sobre cómo asignar una ruta a un sitio web, por ejemplo.
"Hay un lugar que es la representación canónica de la dirección IP de Google, y todas las demás ubicaciones son solo caché", dijo Shoup.
Hay dos formas de obtener los datos necesarios para los servicios que los necesitan. El primer enfoque es sincrónico: la función de servicio al cliente podría solicitarse en tiempo real, o la función de servicio al cliente podría producir un evento al que los otros servicios se suscribirían o escucharían. El segundo enfoque es el enfoque impulsado por eventos, donde, cada vez que hay un cambio de dirección, por ejemplo, se activa un evento que informa a todas las partes necesarias.
"La mayoría de los sistemas [grandes] usan una combinación de esas estrategias", dijo Shoup.
Aparte de los problemas transaccionales, dijo Shoup, todavía existe la necesidad de aplicar análisis en todos los datos. Una implementación de big data por separado o un almacén de datos se puede rellenar periódicamente con datos canónicos, dijo. Pero no debería convertirse en la fuente canónica, eso sería un retorno a las prácticas monolíticas.
Los retos de la consolidación
La necesidad de consolidar los datos de microservicios puede presentar desafíos en un entorno de nube, advirtió el analista de Forrester, Randy Heffner.
"Si bien los entornos de aplicación fracturados siempre han causado dificultades en la administración de datos, a medida que los datos se difunden por todas las aplicaciones SaaS, plataformas en la nube [y] paisajes de IoT... el costo de reunir los datos nuevamente puede ser incrementado por los cargos de la nube por el movimiento de datos y paquetes de acceso a las APIs, una cuota de llamadas a las APIs en la aplicación SaaS", dijo.
Los arquitectos deben repensar las arquitecturas analíticas y desarrollar patrones que distribuyan el análisis a donde residen las partes de los datos, explicó Heffner. Además, los arquitectos deben desarrollar y adoptar patrones avanzados para administrar transacciones que afecten la distribución de datos en múltiples nubes, como los modelos eventuales de coherencia y compensación de transacción.
"Ellos deben entender que los problemas de manejo de errores y la capacidad de recuperación para el manejo de transacciones pueden afectar la experiencia del cliente... si parte de los errores de transacción se producen y el cliente ve datos inconsistentes", agregó.
Los proveedores de gestión de lago de datos son particularmente útiles cuando se trata de la consolidación de datos. Los entornos de administración de lago de datos ayudan a los usuarios a crear inventarios basados en catálogo de datos almacenados en sus entornos de lago de datos, que generalmente se basan en Hadoop, dijo Aslett. Los proveedores clave en este espacio incluyen Alation, Cambridge Semantics, Cask Data, Immuta, Infoworks, Podium Data, Tamr, Unifi Software, Waterline Data y Zaloni. Los entornos de gestión de lagos de datos proporcionados por estos proveedores han evolucionado, dijo Aslett. Por ejemplo, a menudo incluyen funcionalidades tales como colaboración y recomendaciones automatizadas. Algunos han ampliado su capacidad para catalogar datos en un estado de gestión de datos más amplio, incluidas las bases de datos relacionales y el almacenamiento en la nube.
Aslett dijo que los proveedores de gestión de datos "tradicionales", como IBM, Informatica, Hitachi, Talend e incluso los distribuidores de Hadoop, están haciendo planes para abordar la expansión de los datos. Los distribuidores de Hadoop, en particular, están incrementando sus capacidades para identificar y administrar datos en entornos más allá del Sistema de Archivos Distribuidos de Hadoop, dijo Aslett.
Yuen también cree que el mercado comenzará a abordar estos desafíos, particularmente cuando se trata de contenedores y tendencias sin servidor.
"Creo que también [veremos] más y más servicios específicos de almacenamiento para sistemas basados en contenedor y sin servidor, como iniciativas de interfaz de almacenamiento de contenedores y proveedores especializados en la gestión de almacenamiento para estos servicios", dijo.