Kafka, en sí mismo, no es el problema. El verdadero problema es el modelo operativo que muchas organizaciones construyeron alrededor de él y que nunca terminó de actualizarse del todo. Kafka ofrece control y flexibilidad, pero ese control implica operar capacidad, rendimiento, versiones, seguridad, monitoreo y recuperación. La arquitectura queda atrás cuando cada equipo debe resolver esas capacidades por separado y mantenerlas con scripts, herramientas aisladas o procedimientos manuales. Ese es el punto de partida para entender por qué tantas organizaciones sienten que su infraestructura de streaming quedó desactualizada, aun cuando el motor que la sostiene sigue siendo perfectamente vigente.
Por qué Kafka no es el problema, sino el modelo operativo
En este contexto, DIY significa “Do It Yourself” (hazlo tú mismo): un entorno autogestionado en el que la empresa instala, configura, escala, protege, actualiza, monitorea y recupera Kafka y los componentes que lo rodean, incluidos conectores y herramientas operativas. No describe una tecnología distinta ni implica que Kafka sea inadecuado; describe quién asume la responsabilidad de operar la plataforma.
Por eso Kafka no es el problema: el mismo motor puede sostener arquitecturas muy distintas. El problema aparece cuando el modelo operativo obliga a cada equipo a resolver capacidad, seguridad, conectividad, observabilidad y recuperación con procesos manuales y herramientas separadas. La arquitectura quedó pensada para otra era cuando esas responsabilidades siguen fragmentadas aunque hayan crecido el volumen, la criticidad y la cantidad de casos de uso.
Qué señales muestran que la arquitectura no evolucionó
Algunas señales son claras: upgrades difíciles, capacity planning manual, conectores construidos caso por caso, monitoreo centrado en brokers, incidentes que dependen de pocas personas y una proporción creciente del sprint dedicada a plataforma. Otra señal, no menos importante, es que incorporar una fuente o destino requiere un proyecto distinto para cada equipo, en lugar de un proceso estandarizado que se pueda repetir con facilidad y previsibilidad.
Qué exigen hoy la IA y la analítica en tiempo real
Exigen datos actuales, confiables, protegidos, observables y gobernados. No basta con tener un backbone de eventos: hay que conectar sistemas, aplicar contratos y esquemas, controlar accesos, procesar flujos, rastrear el linaje y recuperar la operación cuando falla una dependencia.
Para que esos datos sean útiles en IA y analítica, deben llegar con baja latencia y conservar el contexto necesario para tomar decisiones. También deben estar disponibles de forma continua, mantener calidad y consistencia, cumplir políticas de seguridad y gobernanza, y poder escalar desde un piloto hasta cargas de producción sin crear silos ni copias desactualizadas.
Qué diferencia a una plataforma gestionada y gobernada
La diferencia está en el reparto de responsabilidades. Una plataforma puede automatizar infraestructura, conectividad, controles de seguridad, esquemas, gobernanza, observabilidad y soporte alrededor de Kafka. No elimina el diseño de aplicaciones ni el ownership de los datos; evita que cada equipo reconstruya la misma capa operativa.
Lo que la distingue de un servicio que solo administra brokers es la integración de esas capacidades en una misma plataforma: conectores para incorporar fuentes y destinos, contratos y esquemas para controlar la estructura de los datos, políticas centralizadas de acceso y seguridad, observabilidad de extremo a extremo, procesamiento y mecanismos de resiliencia. Así, los equipos pueden desarrollar casos de uso sobre controles comunes y consistentes, sin ensamblar y mantener una solución diferente para cada pipeline. La plataforma no reemplaza el diseño de las aplicaciones ni la responsabilidad sobre los datos; elimina la necesidad de reconstruir la capa operativa alrededor de cada implementación, algo que resulta cada vez más costoso a medida que crecen el volumen de datos y la cantidad de equipos involucrados.
Compartir nota:
