Por Andrew Tan
Dos hechos que se siguen mezclando
Apache Kafka sigue siendo un protocolo abierto. Puedes ejecutarlo en MSK, en un clúster que operas tú, en Redpanda o en Confluent Platform. El formato de red no fue adquirido.
Confluent, la empresa que convirtió ese protocolo en el stack comercial predeterminado de Kafka, es una compañía de IBM desde el 17 de marzo de 2026. IBM pagó alrededor de 11.000 millones de dólares, 31 dólares por acción. El primer día, el mensaje no fue “seguimos siendo la empresa independiente de Kafka”. El primer día fueron watsonx.data, IBM MQ, webMethods e IBM Z. El Streaming como combustible para una plataforma de datos de IA y automatización híbrida.
Tratar estos dos hechos como un mismo evento te hará dormir durante los próximos 18 meses de decisiones de producto. Sepáralos y la próxima conversación con tu proveedor se volverá mucho más útil.
Lo que realmente se cerró
Ya escribí la comparación técnica de Kafka. Este es el artículo sobre la concentración.
El día del cierre, IBM plasmó su tesis en el título del comunicado de prensa: los datos en tiempo real como motor de la IA empresarial y los agentes. Rob Thomas habló de modelos y agentes que actúan sobre lo que está ocurriendo ahora. Jay Kreps, todavía CEO en esa cita, habló de poner en movimiento los datos del mundo a escala de IBM.
Esa es una apuesta de producto diferente a “el mejor Kafka”.
El mejor Kafka significa reequilibrios de particiones, calidad de conectores, empaquetado de Flink, SKUs en la nube y si tu página de consumer lag sigue funcionando un martes. La apuesta de IBM significa que Confluent Cloud y Platform se orientan hacia watsonx, MQ y el mainframe. El log de Kafka es la rampa de acceso. El destino es el conjunto de IA e integración de IBM.
Puedes estar de acuerdo con esa apuesta. Muchas empresas ya viven dentro de ese conjunto. Pero no debes fingir que es la misma hoja de ruta que Confluent vendía como empresa pública.
El fundador se fue. El protocolo se quedó.
El 13 de agosto, Jay Kreps dio un paso atrás tras casi doce años. Las transiciones de fundadores después de un cierre de 11.000 millones de dólares son normales. También te indican dónde se escriben las decisiones.
Las hojas de ruta solían discutirse en Mountain View, con el reloj de una empresa de Kafka. Ahora se discuten dentro de IBM Software, con el reloj de watsonx y el mainframe. La cadencia de conectores, el empaquetado en la nube y lo que significa “soportado” seguirán ese nuevo reloj.
Una señal concreta apareció a finales de octubre. IBM anunció la integración de watsonx.data para Apache Flink, con un lienzo visual y un SDK de Python que envía trabajos a Confluent Platform for Apache Flink. Eso no es un asesino de Kafka. Es IBM envolviendo el procesamiento de flujos dentro de la línea de producto watsonx.data. Si compraste Confluent porque querías una empresa independiente de streaming, vuelve a leer esa frase.
No estoy diciendo que el producto haya empeorado. No tengo un flujo de telemetría dentro de Confluent Cloud. Lo que afirmo es que el centro de gravedad se ha movido, y se puede ver públicamente.
Kafka como lenguaje, IBM como editor
Piensa en Kafka como un lenguaje. Mucha gente lo habla. La gramática está abierta. IBM compró la escuela más grande que enseñaba el dialecto comercial, imprimía los libros de texto y gestionaba el stand de certificación en la conferencia.
Todavía puedes hablar el lenguaje. Puedes contratar gente que lo hable. Puedes ejecutar un clúster que nunca le envíe un dólar a IBM.
Lo que no puedes asumir es que la ruta comercial predeterminada (Confluent Cloud, Confluent Platform, el catálogo de conectores en el que ya te estandarizaste) vaya a luchar por la independencia de Kafka. Seguirá la plataforma de datos e IA de IBM. Ejecutar un topic en dual hacia watsonx.data recibirá más atención que hacer trivial abandonarlo.
Los proveedores siguen su tesis. Tu trabajo es darte cuenta de que la tesis ha cambiado.
Tres preguntas que tu próximo QBR debería incluir
Salta la diapositiva de “¿seguís comprometidos con Kafka?”. Por supuesto que lo están. Kafka es el asset.
Haz las preguntas operativas que el comunicado de prensa no cubre.
Ejecución dual durante los próximos dos años
Si IBM fusiona SKUs, cambia el nombre de las consolas o te mueve a un plano de control de watsonx, necesitas un período en el que la ruta antigua y la nueva produzcan los mismos resultados. La ejecución dual es aburrida. La ejecución dual es cómo sobrevives a una fusión de proveedores sin un corte de fin de semana.
Replay cuando MQ, Z y un almacén están en el mismo incidente
La mayoría de los equipos de Kafka ya saben cómo rebobinar un consumer group. El caso difícil es el mixto: un stream, una transacción de mainframe, un archivo nocturno de ERP y una tabla Iceberg que alguien ya consultó. El diagrama del día uno de IBM pone todo eso en una misma familia. Tu incidente de un martes por la noche sigue necesitando a una persona que pueda rebobinar uno sin corromper los demás.
Si el batch todavía necesita un segundo orquestador
Si la respuesta es “usa Airflow para los archivos y Confluent para los topics”, no compraste una plataforma. Compraste un conjunto de streaming y mantuviste la división que ya tenías. Pídeles que te muestren un Workflow que reproduzca un archivo tardío y un topic defectuoso con la misma propiedad.
Si tu AE no puede responder esas preguntas sin un arquitecto de soluciones y una semana de retraso, ya tienes tu señal.
El problema que no fue adquirido
IBM compró una empresa de streaming. No compró tu problema de coordinación.
Sigues teniendo que poner al día un trabajo por lotes que se perdió la ventana mientras el stream seguía avanzando. Sigues teniendo que reproducir tres horas de mensajes envenenados sin escribir dos veces en el almacén. Sigues teniendo que unir una dimensión de cambio lento a un topic en vivo. Sigues teniendo que explicarle a un nuevo empleado qué sistema es la fuente de la verdad un viernes por la tarde.
Nada de eso vive en el protocolo de Kafka. El logo de IBM en la consola de Confluent no lo hace más fácil. Parte de ello se vuelve más difícil si el stack comercial está siendo reorientado hacia agentes y watsonx mientras tu carga de trabajo real sigue siendo “hacer que el archivo de pagos y el topic de fraude coincidan”.
Los equipos con los que hablo que están tranquilos con esto no publicaron “Kafka es open source, estamos bien” en Slack. Ya tratan al broker como un transporte y mantienen el runtime (reintentos, dependencias, replay, aprobaciones) en un lugar que controlan.
Dónde encajamos
En layline.io trabajamos con equipos que hablan Kafka y aun así tienen que entregar archivos a las 6 de la tarde. No somos un reemplazo de Kafka ni una alternativa a IBM. Somos el runtime que se sitúa entre batch y streaming para que el trabajo de coordinación no viva dentro del conjunto del proveedor de streaming.
Si la plataforma de IBM es el hogar adecuado para ti, úsala. Solo no confundas “seguimos produciendo registros de Kafka” con “nuestro modelo operativo no ha cambiado”. Los registros pueden verse iguales. La gravedad a su alrededor no puede.
Si estás en Confluent Cloud o Platform e intentas separar la comodidad del protocolo de la gravedad del proveedor, ponte en contacto. Hemos ayudado a equipos a mapear ejecución dual y replay entre batch y stream sin esperar al próximo cambio de marca.
Andrew Tan es un emprendedor en serie y fundador de layline.io, que construye infraestructura de procesamiento de datos empresarial que maneja cargas de trabajo tanto por lotes como en tiempo real a escala.
