¿Qué es IBM Event Automation y cómo gobierna tu entorno Kafka?

La mayoría de los entornos Kafka empiezan ordenados y acaban siendo inmanejables. Un puñado de topics se convierte en cientos, repartidos entre distintos equipos, documentados de forma inconsistente o directamente sin documentar, sin ninguna forma fiable de saber quién publica en un topic, quién lo consume o si es seguro cambiar el esquema. IBM Event Automation existe para resolver ese problema concreto: no sustituyendo Kafka, sino añadiendo una capa de gobernanza y capacidad de descubrimiento por encima.

Esta guía explica qué es IBM Event Automation, por qué la gobernanza de Kafka se vuelve necesaria a escala, cómo funcionan juntos los componentes de la plataforma y cómo encaja con Confluent o con cualquier otro clúster compatible con Kafka que ya tengas en producción.

El problema: topics de Kafka sin gobernanza

Un clúster de Kafka sin una capa de gobernanza funciona bien durante la primera docena de topics. Alguien sabe qué contiene cada uno, quién es su propietario y quién lo consume, porque el equipo es lo bastante pequeño como para mantener ese contexto de forma informal. Eso deja de funcionar en algún punto entre los cincuenta y unos pocos cientos de topics, que es aproximadamente donde acaban la mayoría de los entornos Kafka medianos y grandes al cabo de un par de años.

A partir de ahí, los nuevos consumidores no pueden saber qué contiene un topic sin preguntar por ahí. Los productores cambian un esquema sin saber a quién van a romper. Aparecen topics duplicados porque la persona que necesitaba esos datos no sabía que ya existían en otro lugar. Los equipos de seguridad no pueden responder preguntas básicas sobre quién tiene acceso a qué. Nada de esto es un problema de Kafka. Kafka hace exactamente lo que está diseñado para hacer: mover registros de forma fiable y con baja latencia. La capacidad de descubrimiento, la propiedad y el control de acceso nunca formaron parte de ese diseño, y no aparecen por sí solas a medida que el entorno crece.

La solución provisional a la que recurren primero la mayoría de los equipos es una hoja de cálculo o una página wiki con la lista de topics y propietarios. Funciona durante un tiempo, pero se queda desactualizada respecto al clúster en cuestión de un trimestre, porque nada obliga a mantenerla sincronizada con lo que realmente se está ejecutando. Para cuando alguien se da cuenta de que la documentación está mal, normalmente lleva meses así, y el equipo ha dejado de confiar en ella sin decirlo abiertamente, lo que devuelve el entorno a la casilla de salida: conocimiento tribal, en manos de quien lleva más tiempo allí.

¿Qué es IBM Event Automation?

IBM Event Automation es la plataforma de IBM para gestionar un entorno orientado a eventos construido sobre Kafka. Se sitúa por encima de Kafka en lugar de sustituirlo, añadiendo las funciones de gobernanza, catalogación y procesamiento que Kafka por sí solo no ofrece. La plataforma aplica a los flujos de eventos la disciplina de la gestión de APIs, familiar en herramientas como API Connect: documentar los topics, controlar quién puede acceder a ellos y hacerlos descubribles a través de un catálogo de autoservicio.

También incluye una capa de procesamiento de flujos no-code para crear flujos de eventos sin escribir código, que tratamos con más detalle en nuestra guía complementaria sobre procesamiento de flujos no-code con IBM Event Automation. Este artículo se centra en el aspecto de la gobernanza: cómo Event Automation convierte un conjunto de topics de Kafka sin gestionar en un entorno de eventos descubrible y con control de acceso.

El nombre engloba tres productos independientes pero integrados, y conviene ser precisos al respecto desde el principio, porque las organizaciones suelen adoptar un componente sin los otros. Un equipo que se enfrenta únicamente a un problema de gobernanza no necesita tocar el procesamiento de flujos en absoluto, y un equipo que solo quiere flujos no-code no necesita catalogar antes cada topic. Los componentes están diseñados para adoptarse de forma independiente, según cuál sea el problema más urgente.

Capacidades principales de IBM Event Automation

Las capacidades de gobernanza de Event Automation se centran en hacer que los topics de Kafka se comporten como productos gestionados y documentados, en lugar de como tuberías sin etiquetar.

• Publicar topics en un catálogo de eventos con capacidad de búsqueda, con documentación AsyncAPI adjunta
• Aplicar control de acceso, de modo que los consumidores solicitan y reciben permiso para un topic en lugar de conectarse libremente
• Registrar quién produce y quién consume en cada topic, de forma que sea posible analizar el impacto antes de un cambio de esquema
• Ofrecer un descubrimiento de autoservicio, para que los equipos puedan encontrar y solicitar acceso a topics existentes en lugar de crear duplicados
• Supervisar el estado del clúster de Kafka, el flujo de mensajes y el lag de los consumidores a través de una vista operativa unificada

Componentes principales de Event Automation

IBM Event Automation está formado por tres componentes que se pueden adoptar de forma independiente o conjunta, según lo que la organización ya tenga implementado.

Event Streams

Event Streams es la distribución de Kafka de IBM, que agrupa Apache Kafka con herramientas de producción: exploración de mensajes, balanceo de carga, un schema registry y monitorización del clúster. Las organizaciones que ya ejecutan Kafka en otro lugar, incluido Confluent, no necesitan adoptar Event Streams para usar el resto de la plataforma.

Event Endpoint Management

Event Endpoint Management es la capa de gobernanza, y el componente más directamente responsable de resolver el problema con el que abría este artículo. Publica los topics de Kafka en un catálogo de autoservicio documentado con AsyncAPI, aplica controles de acceso y permite a los consumidores solicitar acceso mediante un flujo de trabajo gestionado, en lugar de una conversación informal.

Event Processing

Event Processing es la capa de procesamiento de flujos no-code, construida sobre Apache Flink pero expuesta a través de un diseñador visual en lugar de código. Es el componente que tratamos en profundidad en nuestro artículo complementario; se incluye aquí porque los topics gobernados y catalogados son también los que se pueden incorporar con más seguridad a un flujo de procesamiento, ya que su contenido y sus propietarios ya se conocen.

Por qué importa la gobernanza de Kafka

La gobernanza no es una casilla de cumplimiento normativo añadida a Kafka a posteriori. Cambia lo que es posible a nivel operativo. Un topic documentado y con control de acceso se puede modificar con confianza, porque el propietario sabe quién depende de él. Uno sin documentar no, porque un cambio de esquema puede romper silenciosamente a tres consumidores de los que nadie se acuerda.

La gobernanza también determina si la adopción de Kafka sigue creciendo o se estanca. Los equipos que pueden descubrir y reutilizar topics existentes avanzan más rápido y evitan pipelines duplicados. Los que no pueden tienden a reconstruir lo que ya existe, porque encontrarlo cuesta más que recrearlo. A escala, esa duplicación se convierte en una carga operativa propia, con varios topics que contienen datos casi idénticos y que acaban desincronizados.

También existe una dimensión de seguridad que suele salir a la luz solo después de un incidente. Sin control de acceso a nivel de topic, la pregunta de «quién puede leer este stream» a menudo se responde con «cualquiera que tenga acceso de red al clúster», lo cual rara vez es la política prevista para un stream que transporta datos financieros o de clientes. Añadir control de acceso después de que un clúster haya crecido sin gestión es posible, pero resulta bastante más difícil que incorporarlo desde el momento en que se crean los topics.

Cómo resuelve IBM Event Automation la gestión de topics de Kafka sin gobernanza

Event Endpoint Management aborda directamente el problema de los topics sin gobernar, al tratar cada topic como un producto con un propietario, documentación y una política de acceso, en lugar de como un stream anónimo al que cualquiera puede suscribirse.

Cuando un equipo quiere consumir de un topic, lo encuentra en el catálogo, lee su documentación AsyncAPI para entender su esquema y su semántica, y solicita acceso a través de la plataforma. El propietario del topic aprueba o deniega esa solicitud, y la concesión queda registrada. Cuando se planifica un cambio de esquema, el propietario puede ver exactamente quién consume el topic y ponerse en contacto antes de aplicar el cambio, en lugar de enterarse después de que algo se rompa.

Esto no requiere migrar datos ni cambiar cómo escriben en Kafka los productores y consumidores. La capa de gobernanza se sitúa junto al clúster existente, catalogando lo que ya hay.

Cómo funciona IBM Event Automation con Confluent/Kafka

Los componentes de gobernanza y procesamiento de Event Automation no se limitan a la distribución Event Streams propia de IBM. Event Endpoint Management y Event Processing pueden conectarse a cualquier clúster compatible con Kafka, incluidos Confluent Platform o Confluent Cloud, mediante protocolos estándar de Kafka. Esto es relevante para las organizaciones que ya han estandarizado su uso de Confluent y no quieren migrar su distribución de Kafka solo para añadir una capa de gobernanza.

En la práctica, esto significa que una organización puede mantener su clúster de Confluent existente como sistema de referencia para los datos de eventos, y adoptar Event Endpoint Management únicamente por el catálogo, la documentación y el control de acceso que añade por encima. La capa de Kafka y la capa de gobernanza están desacopladas por diseño.

Esto también es relevante para las organizaciones que ejecutan Kafka en más de una distribución, algo habitual tras una fusión o adquisición, o simplemente porque distintos equipos tomaron decisiones diferentes con el tiempo. Un único catálogo de Event Endpoint Management puede abarcar varios clústeres de Kafka subyacentes, dando a la organización un solo lugar donde descubrir y solicitar acceso a los datos de eventos, independientemente de en qué clúster residan realmente.

Casos de uso habituales

• Catalogar un entorno Kafka existente que ha crecido más allá del punto en el que el conocimiento tribal informal es suficiente
• Dar a los equipos consumidores acceso de autoservicio a los datos de eventos sin necesidad de que ingeniería intervenga directamente en cada solicitud
• Aplicar control de acceso a streams de eventos sensibles, como los que transportan transacciones financieras o datos personales
• Reducir la creación de topics duplicados haciendo que los topics existentes sean descubribles antes de que un equipo cree uno nuevo
• Preparar una base gobernada antes de añadir procesamiento de streams no-code o personalizado por encima

Consideraciones de implementación

Implantar la capa de gobernanza de Event Automation funciona mejor como un esfuerzo por fases que como un único evento de migración. Catalogar todos los topics existentes de golpe, antes de haber definido la propiedad y la documentación, produce un catálogo en el que nadie confía. Es más eficaz empezar con un subconjunto de topics de alto valor o alto riesgo, dejar bien resuelta la propiedad y la documentación de esos, y expandirse a partir de ahí.

La propiedad también debe asignarse de forma deliberada. Un topic sin un propietario claro y responsable en el catálogo no está mejor gobernado que un topic sin entrada en el catálogo. Las organizaciones que se saltan este paso terminan con un catálogo que enumera topics pero no puede responder quién es responsable de ellos, lo que anula el propósito de tenerlo.

Por último, las políticas de control de acceso deben reflejar cómo trabaja realmente la organización, y no una configuración uniforme de abierto por defecto o bloqueado por defecto. Los streams sensibles con datos financieros o de clientes suelen necesitar flujos de aprobación; las métricas operativas internas, a menudo no. Tratar todos los topics de la misma manera, en cualquiera de los dos sentidos, genera fricción donde no hace falta o exposición donde sí.

Cómo puede ayudar Mimacom

Mimacom ayuda a las empresas a llevar gobernanza a entornos Kafka que han superado la gestión informal, ya se ejecuten sobre IBM Event Streams, Confluent u otra distribución de Kafka. Evaluamos el estado actual de los topics, la propiedad y la documentación de la organización, y después implementamos Event Endpoint Management con un modelo de control de acceso que encaja con cómo opera realmente el negocio. Cuando también hace falta una capa de procesamiento no-code o personalizada, ayudamos a decidir qué encaja en Event Processing y qué necesita un enfoque de ingeniería dedicado.

Preguntas frecuentes

¿IBM Event Automation sustituye a Kafka?

No. Event Automation añade funciones de gobernanza, catalogación y procesamiento por encima de un clúster de Kafka existente. No sustituye a Kafka en sí, y puede ejecutarse contra la distribución Event Streams propia de IBM, Confluent u otro clúster compatible con Kafka.

¿Puede IBM Event Automation gobernar un clúster de Confluent Kafka?

Sí. Event Endpoint Management y Event Processing se conectan a cualquier clúster compatible con Kafka mediante protocolos estándar, incluidos Confluent Platform y Confluent Cloud. Adoptar la capa de gobernanza no requiere abandonar Confluent.

¿Qué documenta exactamente un catálogo de eventos?

Cada topic del catálogo se documenta con AsyncAPI, incluyendo su esquema, su descripción y su propietario. Los consumidores usan esta documentación para entender el contenido de un topic antes de solicitar acceso, y los propietarios la usan para hacer seguimiento de quién depende del topic a la hora de planificar cambios.

Poner orden en un entorno orientado a eventos

Un entorno Kafka sin gobernar no falla de golpe. Se degrada de forma gradual, a través de topics duplicados, esquemas sin documentar y cambios que rompen a consumidores de los que nadie se acuerda. La capa de gobernanza de IBM Event Automation aborda esto directamente, convirtiendo un conjunto de topics anónimos en un catálogo de productos de eventos documentados y con control de acceso, sin necesidad de modificar el clúster de Kafka subyacente.

Las organizaciones que más partido le sacan son las que tratan la gobernanza como una disciplina continua, con propiedad clara y políticas de acceso deliberadas, en lugar de como un ejercicio de catalogación puntual.