Abriendo tu 'legacy’ al tiempo real con Confluent.

Durante los últimos años, se ha estado debatiendo sobre las distintas posibilidades que ofrece el patrón Change Data Capture, y cómo implementar soluciones de este tipo permite construir soluciones reactivas, así como definir casos de uso en tiempo real a partir de sistemas de distinta índole.

Desde Paradigma Digital también hemos hablado sobre ello, y se han publicado una serie de artículos teórico/prácticos donde se analizan distintas herramientas que nos permiten implementar soluciones de CDC: Debezium y Oracle Golden Gate, además de otras publicaciones (este podcast y este webinar) en las que se detalla, en profundidad, la herramienta Debezium y sus posibilidades, focalizando en la modernización de aplicaciones y sistemas.

En este artículo vamos a ampliar el surtido de herramientas que nos permiten implementar soluciones de CDC echando un vistazo al ecosistema Confluent, analizando las posibilidades que ofrece y lo que aporta respecto a otras herramientas, además de implementar una solución de CDC y definir un caso de uso para la replicación en tiempo real de una base de datos.

¿Qué es Confluent?

Si estás leyendo este artículo, posiblemente conozcas o hayas oído hablar de Apache Kafka y de Confluent, pero vamos a citar brevemente ambas plataformas y la motivación detrás de la creación del ecosistema Confluent.

Apache Kafka es una plataforma que fue creada como una cola de mensajería distribuida basada en commit log, con la finalidad de integrar sistemas de distinta índole de forma fácil y eficaz. El éxito de Kafka ha hecho que esté evolucionando a pasos agigantados y que haya pasado de ser una simple cola de mensajería a una plataforma event streaming completa, muy utilizada en sistemas en producción.

Este hecho ha supuesto que se tenga la necesidad de completar la plataforma Apache Kafka con distintas funcionalidades adicionales que aporten valor y enriquezcan la experiencia de la transmisión y procesamiento de eventos. Debido a esto, surgen distintas distribuciones que implementan Apache Kafka, entre ellas, el ecosistema Confluent.

El ecosistema Confluent fue creado por los desarrolladores originales de Apache Kafka y se ha convertido en una de las distribuciones más completas del mercado, ofreciendo muchas funcionalidades adicionales que ayudan, y mucho, en la creación de sistemas orientados a eventos, como pueden ser: funcionalidades para el gobierno del dato, integración, stream processing, trazabilidad, mantenimiento, etc.

La documentación sobre Confluent y sus funcionalidades es muy extensa. Durante el desarrollo del artículo, nos centraremos en cómo el ecosistema Confluent nos ayuda a implementar soluciones de CDC y abre la puerta a la modernización de sistemas y aplicaciones en tiempo real.

¿Cómo podemos implementar CDC con Confluent?

Para poder construir una solución de CDC, Confluent implementa un gran conjunto de conectores que se integran con una distribución de Kafka Connect configurada dentro de su ecosistema.

Pero… ¿Kafka Connect? ¿Conectores? ¿Qué son?

Kafka Connect es una herramienta que permite transmitir datos entre Apache Kafka y otros sistemas de datos de forma escalable y confiable. Esta funcionalidad facilita la creación de conectores que son las funcionalidades que permiten mover grandes conjuntos de datos entre ambos sistemas.

Si conocéis o habéis seguido nuestras publicaciones sobre Debezium, podéis daros cuenta de que la forma en la que se puede construir una solución de CDC (tanto en Debezium como en Confluent) es similar. Está basada en la construcción de conectores compatibles con Kafka Connect, que permitan detectar cambios en el origen y transmita los datos a Apache Kafka.

Entonces, ¿qué diferencia hay entre Debezium y Confluent?

Salvando que el alcance de una herramienta y otra es completamente diferente y que Confluent es un ecosistema que ofrece otras muchas funcionalidades respecto a la transmisión de datos y procesamiento de eventos, la gran diferencia, si nos basamos en soluciones de CDC, se puede ver en los conectores.

Confluent proporciona un gran número de conectores. No solo para motores de bases de datos como hace Debezium, sino que existen conectores para otro tipo de orígenes, como pueden ser colas de mensajería o productos comerciales. A su vez, ofrece un portal llamado Confluent Hub donde se muestran todos los conectores que se pueden configurar en Kafka Connect, con toda la documentación necesaria para hacer uso de cada uno de ellos.

Un dato curioso que deja claro el alcance que tiene Confluent, dentro del portal de conectores podemos encontrar algunos de los conectores de Debezium validados por el propio equipo de Confluent.

¿Qué conectores ofrece Confluent?

En el apartado anterior ya hemos adelantado la gran cantidad de conectores que ofrece el ecosistema Confluent, pero vamos a catalogar los conectores que podemos encontrar para ver las posibilidades que estos ofrecen.

En primer lugar, podemos catalogar a los conectores por su tipo, es decir, la finalidad para los que han sido creados.

1. Source: son los conectores que leen (o capturan) la información de sistemas externos y producen eventos en topics de Apache Kafka.

Como dato interesante, los conectores de Debezium serían de este tipo, aunque limitando el origen a motores de bases de datos.

2. Sink: Son los conectores que consumen eventos de Apache Kafka y exportan esa información a sistemas externos.

3. Transforms: Los conectores de este tipo permiten manipular y transformar la información a medida que fluyen desde el origen hasta el destino. Esta funcionalidad se conoce como SMT (Single Message Transformations).

Como veremos más tarde, la suma de estos tipos de conectores, source, sink y transforms, nos van a ayudar a la modernización de sistemas y la construcción de soluciones en tiempo real.

Por otro lado, podemos catalogar los conectores dado el soporte empresarial de dichos conectores: soporte por parte de Confluent, soporte por el partner que se encarga de mantener el conector o sin soporte. Respecto a este último, aunque no tenga soporte oficial, siempre se puede apoyar de la comunidad Confluent.

Además, también existe la posibilidad de catalogar por la constatación o verificación del funcionamiento de los conectores: los que son implementados por Confluent, probados por Confluent o que tienen distintos niveles de verificación de compatibilidad con el ecosistema Confluent.

Para finalizar, y no menos importante, se puede catalogar a los conectores por la licencia (y coste) para su uso: Premium, Commercial y Libre.

Este catálogo tan extenso de conectores nos permite, de una forma relativamente sencilla, construir soluciones de CDC a partir de sistemas de distinta índole, ofreciendo a dichos sistemas un gran conjunto de posibilidades.

Usando conectores en Confluent

Ya hemos visto que las piezas fundamentales para implementar soluciones de CDC con Confluent son Kafka Connect, los conectores y, obviamente, Apache Kafka. Pues bien, ahora vamos a ver qué posibilidades ofrece el ecosistema Confluent para poder registrar un conector.

Para este apartado, vamos a suponer que se tiene la infraestructura necesaria y la plataforma Confluent configurada. Más tarde, veremos un ejemplo práctico en el que se muestra cómo montar un ecosistema Confluent en local con Docker.

El primer paso que se tiene que dar para poder usar un conector en el ecosistema Confluent es instalar las librerías del conector en Kafka Connect, que nos permita hacer uso de dicho conector. Hay dos formas:

• Confluent proporciona una comando, confluent-hub, que permite instalar en Kafka Connect las librerías necesarias de un conector que esté publicado en Confluent Hub.

confluent-hub install mongodb/kafka-connect-mongodb:1.6.1

Como podemos ver en la instrucción, se van a instalar las librerías necesarias para poder usar un conector que permita leer (o detectar) los datos de una base de datos MongoDB.

• La otra opción es la de descargar los binarios del conector y copiarlos directamente en la ruta donde se almacenan los conectores dentro de Kafka Connect.

connect:/usr/share/confluent-hub-components/

Esta opción sirve para conectores que están en Confluent Hub como conectores creados por la comunidad y no están publicados o, incluso, conectores desarrollados de forma particular.

Una vez instaladas las librerías del conector que se quiere usar, el siguiente paso es registrar el conector con la configuración que se necesite: credenciales, servidor origen/destino, etc. En este caso, también hay dos maneras:

• Hacer uso del panel de administración que proporciona Confluent (Control Center). De esta forma, y de manera muy sencilla, permite configurar el conector con las configuraciones necesarias en cada caso.

Las imágenes de arriba ilustran la manera de registrar un conector para una base de datos MongoDB y las facilidades que ofrece la funcionalidad Control Center del ecosistema Confluent.

• La otra manera es llamar a la interfaz proporcionada por la API REST de Kafka Connect que permite registrar un conector a través de una configuración dada.

curl -i -X POST -H "Accept:application/json" -H "Content-Type:application/json" connect:8083/connectors/ -d @conector-mongo-configuration.json

La instrucción anterior es un ejemplo de cómo llamar a la API REST de Kafka Connect (operación POST) para registrar un conector.

La parte más incómoda/compleja de registrar un conector de esta manera es la necesidad de conocer perfectamente cómo hay que definir dicho conector, aunque la documentación suele ser muy completa.

Como nota interesante, tanto la instalación como el registro de todos los contenedores (independientemente del tipo de conector) suelen ser iguales.

Para finalizar, si la configuración es la adecuada, ya estará la solución de CDC implementada. Será capaz de detectar los cambios producidos en el origen (en este caso, una base de datos MongoDB) y con posibilidad de explotar un sin fin de oportunidades.

Manos a la obra

A partir de los conceptos que hemos visto anteriormente, vamos a implementar un caso práctico en el que se construye una solución de CDC y cómo ésta nos abre la posibilidad de replicar una base de datos en tiempo real apoyándonos de las funcionalidades de la plataforma Confluent.

El código y la documentación necesarios para montar la infraestructura, tanto la solución de CDC con Confluent como el caso de uso para la replicación en tiempo real, está accesible en el siguiente repositorio.

Contexto

Vamos a simular el siguiente contexto.

Nos encontramos en una situación en la que una empresa del ámbito Retail gestiona toda su cartera de clientes a través de una aplicación con tecnología obsoleta y una base de datos PostgreSQL (versiones sin soporte), que no cumple con los requisitos necesarios que demanda el negocio.

Desde el equipo directivo de la empresa, se tiene como prioridad absoluta cumplir con los requisitos técnicos de performance en cuanto a la gestión de los clientes, ya que lo ven como aspecto clave para destacar ante la competencia.

Teniendo en cuenta que partimos de un escenario técnico complejo, se ve la necesidad de tener que migrar los sistemas actuales a sistemas más modernos que proporcionen mejores prestaciones.

Solución CDC con Confluent

¿Cómo resolvemos este problema? Existen muchas formas de poder hacer una migración.

En este caso de uso vamos a ver cómo Confluent nos ayuda a resolver esta situación a través de las funcionalidades que ofrece para implementar una solución de CDC.

La idea detrás de ello es que, apoyándonos de las funcionalidades que proporciona Confluent, vamos a poder transmitir la información que tiene la base de datos origen a Kafka de forma inmediata y con un impacto mínimo en el sistema productivo. Esto nos va a permitir realizar una migración (o transformación) menos dura.

Como hemos visto anteriormente, Confluent nos proporciona un ecosistema con distintas funcionalidades, por lo que vamos a hacer uso de Kafka Connect y Kafka para resolver los problemas.

En primer lugar, montamos la infraestructura necesaria para tener el ecosistema Confluent en funcionamiento con lo que necesitamos.

A continuación registramos el conector en Kafka Connect de forma que permita detectar los cambios realizados en la base de datos origen.

De esta forma, ya seríamos capaces de monitorizar todo lo que ocurre en el origen y transmitir la información a Kafka.

Replicación en tiempo real

Por último, y una vez implementada nuestra solución de CDC, tenemos que definir la estrategia que nos permita construir un motor de base de datos con una mejor performance que cumpla con las necesidades a corto, medio y largo plazo.

En este caso, se elige configurar un clúster de MongoDB en la nube que nos permita cumplir con las expectativas.

Y finalmente, nos apoyamos en las funcionalidades de Confluent para poder transmitir la información de Kafka al nuevo destino de datos.

En este punto ya somos capaces de hacer una replicación en tiempo real de la parte ‘legacy’ al nuevo sistema, que nos va a permitir implementar soluciones más acordes a las necesidades actuales.

Este caso práctico es simple, con la finalidad de ver como Confluent puede ayudarnos a implementar soluciones de CDC. En el repositorio adjunto, se detalla cada uno de los pasos que hemos realizado para poder implementar una solución de este tipo.

¿Solo CDC?

En las distintas publicaciones que hemos hecho hablando sobre CDC, siempre hemos insistido sobre las posibilidades que nos ofrece, ya que creamos una solución reactiva capaz de detectar cambios en un origen y nos aprovechamos de esto para crear nuevas soluciones mucho más dinámicas y acordes a las necesidades actuales.

Una de esas necesidades es la de actuar en tiempo real.

Implementar una solución CDC nos aporta eso, que a partir de un origen tradicional, vamos a ser capaces de implementar distintas funcionalidades que nos permitan tratar la información de la forma deseada y de forma inmediata.

Y en esta parte, el ecosistema Confluent destaca por encima de las otras. Nos proporciona más herramientas para implementar esas soluciones en tiempo real, herramientas para el procesamiento y enriquecimiento de eventos, conectores sink que nos permiten transmitir la información a nuevos sistemas, etc. De hecho, en el caso de uso expuesto anteriormente, no solo hemos replicado la información de una base de datos a otra totalmente distinta, sino que además, lo hemos realizado en tiempo real.

Además existe Confluent Cloud (cloud-native Kafka service), una plataforma que permite gestionar todo el ecosistema Confluent en la nube y, salvo diferencias en los conectores soportados, tenemos disponibles las mismas funcionalidades que en una plataforma on-premise. De esta forma, se simplifica la complejidad de mantener y configurar un entorno de estas características.

Con la ayuda de la plataforma Confluent, podemos pasar de nuestros sistemas ‘legacy’ a sistemas en la nube de manera relativamente sencilla y en tiempo real.

Entonces, ¿qué solución es mejor para CDC?

Hay muchos factores a tener en cuenta a la hora de elegir la mejor herramienta (o distribución) para implementar una solución de CDC. Entonces, ¿el ecosistema Confluent es la mejor solución? Pues… depende.

Lo único claro es que hay que seleccionar la herramienta que mejor se adapte a la propia situación de cada uno. Algunos factores, como el conocimiento técnico, la complejidad de los casos de uso, los partnership o las posibilidades financieras, son indicativos de qué herramientas se adaptan mejor o peor.

Evidentemente, no todas las herramientas son iguales y habrá algunas más completas que otras. Pero dependiendo de la necesidad y de la visión futura de negocio de cada uno, pueden ser más beneficiosas y fáciles de implementar unas que otras.

Referencias

• Documentación Apache Kafka.
• Documentación Kafka Connect.
• Documentación Confluent.
• Documentación Confluent Hub.
• Documentación Confluent Cloud.