Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Apache Kafka es la columna vertebral de la infraestructura de datos en tiempo real de miles de organizaciones en todo el mundo. Su arquitectura de alto rendimiento y tolerante a fallos lo ha convertido en la opción predeterminada para la transmisión de eventos, los flujos de datos y la mensajería de misión crítica en sectores que van desde los servicios financieros hasta el comercio electrónico. Sin embargo, el ritmo acelerado de lanzamientos de Kafka hace que los periodos de soporte de las versiones finalicen mucho más rápido de lo que la mayoría de los equipos empresariales esperan, y cuando llega la fecha de fin de vida útil (EOL) de Apache Kafka, el riesgo va mucho más allá del propio broker.
En este artículo se explica qué implica realmente el fin del ciclo de vida de Kafka para los equipos de infraestructura de datos, dónde se esconde el verdadero riesgo de seguridad, por qué la ruta de actualización a Kafka 4.0 es más exigente que un simple cambio de versión y cómo el servicio Endless Lifecycle Support (ELS) de TuxCare te permite mantener una cobertura total en materia de seguridad y cumplimiento normativo sin obligarte a realizar una actualización para la que tus equipos aún no están preparados.
Principales conclusiones
- Las dependencias multiplican tu superficie de vulnerabilidad: Cuando una versión de Kafka llega al final de su vida útil, quedas limitado a las versiones específicas de las dependencias con las que se suministró. Con el tiempo, esas versiones fijas quedan fuera de sus propios periodos de soporte de los proveedores originales, lo que te deja expuesto a vulnerabilidades sin parchear y sin una ruta de actualización clara.
- Las actualizaciones precipitadas son costosas y arriesgadas: La transición de Kafka 3.x a 4.x requiere una migración obligatoria de ZooKeeper a KRaft, actualizaciones de la versión de Java, cambios en la compatibilidad de la API del protocolo y la eliminación de herramientas, todo lo cual exige una planificación cuidadosa y pruebas exhaustivas, no plazos ajustados.
- El fin de la vida útil (EOL) de Apache Kafka no implica el fin de la seguridad: TuxCare ELS amplía la cobertura de seguridad para estas versiones EOL y sus árboles de dependencias, de modo que las organizaciones puedan mantener la seguridad y el cumplimiento normativo mientras planifican una actualización deliberada y con los recursos adecuados según su propio calendario.
¿En qué consiste el ciclo de vida del producto Apache Kafka?
Kafka sigue un ciclo de lanzamiento basado en plazos establecido en 2016. La comunidad publica una nueva versión menor aproximadamente cada cuatro meses, lo que supone unas tres versiones al año. A cada versión se le asigna una rama con un número de versión, por ejemplo, 3.7, 3.8, 3.9, 4.0, con su propia línea de parches.
La comunidad ofrece soporte para las tres últimas versiones menores en todo momento, lo que se traduce en un periodo de soporte de entre 12 y 16 meses aproximadamente por cada versión. Kafka no publica por adelantado fechas oficiales de fin de vida útil; una versión alcanza efectivamente el estado de fin de vida útil (EOL) de Apache Kafka cuando desaparece de la lista de versiones compatibles en la página oficial de descargas a medida que se van acumulando versiones más recientes. En la práctica, esto significa que, cada cuatro meses, una versión deja de contar con el soporte de la comunidad sin apenas aviso previo.
Calendario actual de soporte para las versiones de Kafka:
| Versión | Fecha de publicación | Fecha de fin de vida útil | Estado |
| Kafka 3.7 | Febrero de 2024 | Julio 2024 | EOL |
| Kafka 3.8 | Julio 2024 | Noviembre 2024 | EOL |
| Kafka 3.9 | Noviembre 2024 | A mediados de 2026 | Activo |
| Kafka 4.0 | Marzo 2025 | Julio 2026 | Activo |
| Kafka 4.1 | Septiembre 2025 | Noviembre 2026 | Activo |
| Kafka 4.2 | Febrero 2026 | May 2027 | Activo |
Nota: Kafka no publica fechas oficiales de fin de vida útil. Estos plazos se derivan de la política de soporte de la comunidad, basada en tres versiones consecutivas, y de los intervalos aproximados de cuatro meses entre lanzamientos.
Este ritmo es agresivo para los estándares empresariales. Las organizaciones que operan en sectores regulados, o que gestionan infraestructuras complejas de flujos de datos en las que las actualizaciones requieren ciclos de validación prolongados, se encuentran habitualmente utilizando versiones que han superado discretamente su fecha de fin de vida útil antes de que la actualización prevista esté lista para ejecutarse.
¿Qué implica el fin de la vida útil (EOL) de Apache Kafka para la infraestructura de datos?
En el caso de un servidor de aplicaciones sencillo, llegar al final de su ciclo de vida significa que el sistema deja de recibir parches. Sin embargo, para las organizaciones que utilizan Kafka como sistema nervioso central de su infraestructura de datos —conectando productores, consumidores, canalizaciones de Kafka Connect, aplicaciones de Kafka Streams y sistemas de análisis posteriores—, el panorama es estructuralmente diferente y considerablemente más complejo.
No habrá más parches de seguridad tras la fecha de fin de vida útil
Una vez que una versión de Kafka llega al final de su ciclo de vida, la comunidad de Apache deja de publicar correcciones de seguridad para ella. Cualquier vulnerabilidad que se detecte después de la fecha de fin de vida útil, ya sea en el propio broker, en el worker de Kafka Connect o en las bibliotecas de cliente, no recibirá un parche oficial para esa versión. La única solución que ofrece la comunidad es actualizar a una versión compatible.
Para los equipos que gestionan grandes clústeres de Kafka críticos para la producción, en los que las actualizaciones requieren pruebas exhaustivas, una validación coordinada de los procesos y una secuencia de implementación minuciosa, esto no siempre es posible en un plazo tan breve. El lapso de tiempo que transcurre entre el momento en que entra en vigor el estado de fin de vida útil (EOL) y el momento en que, de forma realista, se puede completar y validar una actualización es precisamente cuando se acumulan las vulnerabilidades sin parchear.
Riesgos de seguridad y cumplimiento normativo tras el fin de la vida útil
Las consecuencias en materia de cumplimiento normativo derivadas del uso de una versión de Kafka fuera de soporte son directas. La norma PCI DSS (requisito 6.3.3) exige que los parches críticos y de alta gravedad se instalen en el plazo de un mes desde su publicación; sin embargo, en una versión de Apache Kafka fuera de soporte no hay parches que instalar, lo que hace imposible cumplir con la normativa por los medios habituales. Los auditores de SOC 2 señalan el software fuera de ciclo de vida en entornos de producción. Ejecutar un clúster de Kafka en una versión sin soporte técnico genera lagunas en la documentación que salen a la luz en los cuestionarios de seguridad, retrasan las certificaciones de los proveedores y, en los sectores regulados, bloquean las renovaciones de los clientes.
Para las organizaciones en las que Kafka se encuentra dentro del ámbito de aplicación de la norma PCI, trata datos de carácter personal o sustenta servicios sujetos a obligaciones contractuales de SLA, el riesgo de incumplimiento derivado de este fin de vida útil no es meramente teórico. Se trata de una deficiencia de auditoría a la espera de materializarse.
Historial de CVE: lo que revela el registro de vulnerabilidades
El historial de vulnerabilidades CVE de Kafka ilustra el tipo de vulnerabilidades que quedan sin parchear de forma permanente en las versiones que han llegado al final de su ciclo de vida.
CVE-2023-25194 (NVD CVSS 3.1: 8,8 Alto) reveló un vector de ejecución remota de código y denegación de servicio en Kafka Connect. Al configurar las propiedades SASL JAAS del cliente Kafka de un conector para que hicieran referencia a un servidor LDAP malicioso, un operador autenticado podía provocar la deserialización de datos no fiables en el trabajador de Connect, lo que permitía la ejecución de código arbitrario si había gadgets disponibles en la ruta de clases. Esto afectaba a los clústeres de Kafka desde la versión 2.3.0, y el problema era lo suficientemente grave como para que IBM publicara boletines de seguridad sobre múltiples productos, entre ellos IBM Maximo Application Suite e IBM Business Automation Workflow. La solución requería actualizar a versiones parcheadas; las versiones antiguas fuera de soporte que ejecutaban Kafka Connect seguían expuestas sin que hubiera una vía de corrección oficial disponible.
CVE-2025-27819 (NVD CVSS 3.1: 7,5 Alto) es una continuación de CVE-2023-25194, que reveló que la misma vulnerabilidad SASL JAAS JndiLoginModule existía en los brokers de Kafka, no solo en Kafka Connect, y afectaba a las versiones 2.0.0 a 3.3.2. El ataque requiere acceso de red al clúster y permiso AlterConfigs en el recurso del clúster. Un ataque exitoso permite a un atacante establecer conexiones arbitrarias con un servidor LDAP controlado por él y provocar condiciones de denegación de servicio. Se hizo público en junio de 2025, y la corrección que desactiva los módulos de inicio de sesión problemáticos de forma predeterminada solo se incluyó en las versiones 3.9.1 y 4.0.0. Las ramas al final de su vida útil no recibieron ninguna actualización.
Se trata precisamente de una clase de vulnerabilidades relacionadas con vectores de ejecución remota de código (RCE) en la infraestructura central de Kafka, cuya corrección requiere actualizaciones de versión, lo que se convierte en una exposición sin solución definitiva en las versiones que han llegado al final de su vida útil (EOL).
El riesgo oculto: el árbol de dependencias de Kafka
La superficie de vulnerabilidad de una implementación de Kafka no se limita al binario del broker. Kafka incluye un conjunto considerable de dependencias que conllevan sus propios riesgos de seguridad, y cuando Kafka llega al final de su ciclo de vida, el problema no es que esos proyectos de origen dejen de publicar parches. El problema es que quedas atado a las versiones específicas de las dependencias que la versión de Kafka al final de su ciclo de vida fijó, y esas versiones fijas, con el tiempo, quedan fuera de los periodos de soporte de sus propios proyectos de origen.
La biblioteca `kafka-clients` por sí sola incluye dependencias de compresión, entre las que se encuentran `snappy-java`, `LZ4-java` y `zstd-jni`. El broker y Kafka Connect incorporan `Jackson Databind` y los módulos relacionados de Jackson para el procesamiento de JSON, `Netty` para el transporte de red, y `slf4j` con `Log4j2` para el registro de eventos. Las versiones anteriores de Kafka dependían de Apache ZooKeeper, un proyecto con su propio historial de vulnerabilidades CVE, para la gestión de metadatos del clúster. Las herramientas del broker incluyen RocksDB para los almacenes de estado de Kafka Streams, y la biblioteca estándar completa de Scala se incluye como dependencia de tiempo de ejecución.
Cada una de estas dependencias tiene su propia serie de CVE de origen. La biblioteca snappy-java, por ejemplo, estuvo directamente implicada en el CVE-2023-34455 (NVD CVSS 3.1: 7,5 Alta), una vulnerabilidad de denegación de servicio que afectaba a las versiones de Kafka 0.8.0 a 3.5.0, en la que una carga maliciosa comprimida con snappy-java podía provocar que los brokers asignaran cantidades arbitrariamente grandes de memoria del montón, lo que daba lugar a una excepción OutOfMemoryException y a una denegación de servicio en todo el clúster. Jackson Databind ha generado a lo largo de su historia docenas de CVE de alta gravedad relacionadas con la deserialización insegura. Netty tiene su propio historial de vulnerabilidades en la capa de red.
Cuando una versión de Kafka alcanza el estado de fin de vida útil (EOL), dejas de recibir actualizaciones de Kafka que actualicen automáticamente las versiones de esas dependencias. Quedará limitado a las versiones que la versión de Kafka en EOL haya fijado, y es posible que esas versiones específicas dejen de recibir, con el tiempo, correcciones retrocompatibles de sus propios proyectos de origen. El resultado es el mismo: los escáneres de vulnerabilidades que se ejecutan en implementaciones de Kafka en EOL generan hallazgos en todo el árbol de dependencias que no tienen una vía de corrección directa, lo que deja a los equipos de seguridad con una lista cada vez mayor de resultados de análisis sin resolver y sin una ruta de actualización compatible dentro de la versión en EOL.
Opciones para garantizar la seguridad y el cumplimiento normativo
Las organizaciones que utilizan versiones de Apache Kafka llegadas al final de su ciclo de vida tienen dos opciones. Una de ellas implica un esfuerzo técnico considerable, riesgos operativos y plazos prolongados. La segunda, el servicio «Endless Lifecycle Support» de TuxCare, subsana inmediatamente las brechas de seguridad.
Opción 1: Actualizar a la versión actual de Kafka
La solución a largo plazo consiste en actualizar el clúster de Kafka a una versión que cuente actualmente con soporte técnico. Las versiones que actualmente reciben soporte técnico activo son Kafka 3.9, 4.0, 4.1 y 4.2, todas ellas con cobertura de parches continua.
La realidad práctica, sobre todo en lo que respecta a la transición de la versión 3.x a la 4.x, es que se trata de una de las actualizaciones más exigentes en la historia de Kafka. Kafka 4.0 elimina por completo la compatibilidad con ZooKeeper; los clústeres que aún operan en modo ZooKeeper deben completar la migración de metadatos de ZooKeeper a KRaft antes de poder actualizar a la versión 4.0 o a cualquier versión posterior. Para los clústeres con versiones anteriores de Kafka, la ruta de migración puede requerir varios pasos intermedios: actualizar a la versión 3.4, actualizar ZooKeeper a la versión 3.8, actualizar a la versión 3.9, ejecutar la migración de metadatos de ZooKeeper a KRaft y, a continuación, pasar a la versión 4.0. Kafka 4.0 también elimina por completo la compatibilidad con Java 8 y requiere Java 17 para los brokers y las herramientas, elimina MirrorMaker 1 sin ruta de migración in situ, elimina las versiones obsoletas de la API del protocolo de cliente y elimina la API transformValues() de Kafka Streams. Cada uno de estos cambios debe abordarse antes de poder proceder a la actualización. Para las organizaciones que gestionan grandes entornos de Kafka que dan soporte a múltiples equipos y flujos de trabajo, una actualización a la versión 4.x debidamente planificada se mide en meses, no en semanas.
Opción 2: Soporte de ciclo de vida ampliado de TuxCare: la opción recomendada
Esta es la opción que resuelve el problema inmediato sin generar otros nuevos. El servicio «Endless Lifecycle Support» de TuxCare para Kafka te permite seguir utilizando tu versión actual de Kafka en producción, al tiempo que recibes una cobertura continua de parches de seguridad para el broker y su árbol de dependencias, que se distribuyen a través de tu cadena de herramientas existente, sin necesidad de realizar una migración obligatoria.
La brecha de seguridad se subsana de inmediato. Se mantiene su postura de cumplimiento normativo. Sus equipos tienen libertad para planificar la actualización adecuada en un plazo que tenga sentido desde el punto de vista operativo, incluyendo el margen de tiempo adicional necesario para ejecutar correctamente la migración de ZooKeeper a KRaft, validar la compatibilidad de las versiones de Java en toda su pila de aplicaciones y coordinar el despliegue en todos los servicios productores y consumidores que dependen de su clúster de Kafka. Sin actualizaciones forzadas bajo la presión de los plazos, sin emergencias de cumplimiento normativo, sin fallos de compatibilidad en la infraestructura de producción que sustenta los flujos de datos en tiempo real.
Los riesgos de precipitarse al actualizar a Kafka
Cuando aparece un estado de fin de vida útil (EOL) en un panel de control de seguridad y el equipo de cumplimiento normativo empieza a hacer preguntas, la presión para actuar de inmediato es real. Entender lo que realmente implica una actualización apresurada de Kafka es tan importante como comprender el propio riesgo.
En qué consiste realmente una actualización de Kafka
Una actualización adecuada de Kafka, especialmente de la versión 3.x a la 4.x, es un proyecto de infraestructura que se desarrolla en varias fases, no un simple cambio de versión. Requiere planificar la ruta de actualización en función de la versión actual y el modo de metadatos, ejecutar las actualizaciones intermedias necesarias, completar la migración de ZooKeeper a KRaft si procede, realizar reinicios progresivos de los brokers en todo el clúster, validar que todas las aplicaciones cliente sigan siendo compatibles con la nueva versión del broker, verificar que todos los conectores de Kafka Connect funcionen correctamente en el clúster actualizado, probar las aplicaciones de Kafka Streams ante cualquier cambio en la API y ejecutar implementaciones coordinadas a través de los entornos de desarrollo, staging y producción.
Adaptación del código: Kafka 4.0 elimina las API obsoletas, incluyendo transformValues() en Kafka Streams y las versiones heredadas de la API del protocolo. Las aplicaciones que utilicen cualquiera de las API eliminadas deben actualizarse antes de que pueda procederse a la actualización del clúster.
Verificación de compatibilidad: Todos los productores, consumidores, conectores de Kafka Connect y aplicaciones de Kafka Streams del ecosistema deben verificarse con respecto a la versión de Kafka de destino. Un solo cliente o conector incompatible puede provocar fallos en el flujo de datos que afecten a los sistemas posteriores.
Adaptación de la cadena de herramientas: Es necesario revisar y actualizar los flujos de CI/CD, los scripts de implementación, las configuraciones de monitorización y las definiciones de infraestructura como código que hacen referencia a configuraciones específicas de Kafka, especialmente en lo que respecta a los cambios de configuración de KRaft que consolidan el directorio kraft/config en el directorio config principal en la versión 4.0.
Carga de trabajo de las pruebas: No se pueden omitir las pruebas de integración exhaustivas a lo largo de todo el proceso, desde los productores hasta los consumidores, pasando por los intermediarios. Los cambios en el comportamiento del reequilibrio, las nuevas implementaciones del coordinador de grupo y los cambios en la versión del protocolo deben validarse bajo una carga realista antes del lanzamiento en producción.
¿Qué ocurre cuando se precipita una actualización?
Cuando los equipos se ven obligados a acelerar este trabajo bajo la presión de los plazos, las consecuencias son previsibles y siguen un patrón constante.
Aumento de la carga de asistencia técnica: Los problemas de compatibilidad que no se detectan durante las pruebas intensivas salen a la luz en producción. Los picos de retraso en los consumidores, los fallos en los conectores y el comportamiento inesperado del reequilibrio generan una oleada de incidencias que los equipos de ingeniería y operaciones deben absorber además de sus cargas de trabajo habituales.
Inestabilidad del sistema: Los clústeres de Kafka sustentan los flujos de datos de los que dependen los sistemas posteriores. Los sutiles cambios de comportamiento introducidos por una actualización en la asignación de particiones, en la coordinación de los grupos de consumidores y en la gestión del almacén de estado de Kafka Streams pueden provocar fallos intermitentes que son difíciles de reproducir y que se manifiestan con volúmenes de datos de producción que los entornos de preproducción rara vez alcanzan.
Acumulación de deuda técnica: Las soluciones provisionales implementadas bajo presión de tiempo se convierten en permanentes. Las aplicaciones se adaptan rápidamente para superar las comprobaciones de compatibilidad, en lugar de acumular adecuadamente los supuestos que crean problemas para el siguiente ciclo de actualización. El problema del fin de vida útil (EOL) de Apache Kafka se aplaza, no se resuelve.
Costes imprevistos: Las horas de ingeniería de emergencia, los retrasos en el lanzamiento de funciones, los gastos generales de respuesta a incidentes y el coste de oportunidad que supone que los ingenieros de datos sénior dediquen su tiempo a depurar fallos en el proceso de producción en lugar de desarrollar nuevas capacidades se acumulan rápidamente y de formas difíciles de predecir con antelación.
La solución sencilla: TuxCare ELS para Apache Kafka EOL
TuxCare ofrece soporte técnico de ciclo de vida ilimitado para las versiones de Kafka que han llegado al final de su vida útil. En lugar de forzar una actualización del clúster para la que tus equipos aún no están preparados, puedes seguir ejecutando tu implementación actual en fase de fin de vida útil con una cobertura continua de parches de seguridad a través de tu cadena de herramientas de compilación e implementación existente.
TuxCare lleva más de una década dedicándose a esto, proporcionando parches de seguridad para sistemas operativos, entornos de ejecución, bibliotecas y marcos de aplicaciones que han llegado al final de su ciclo de vida. Han distribuido más de 220 000 parches de seguridad en todo el ecosistema de código abierto. Cuando afirman que saben cómo mantener seguras las versiones EOL a escala empresarial, no se trata de mera retórica comercial. Lo han hecho a gran escala y de forma constante.
Cobertura completa del árbol de dependencias: El ELS de TuxCare para Apache Kafka cubre el broker y sus dependencias directas y transitivas, incluyendo snappy-java, Jackson Databind, Netty y otras bibliotecas que conllevan su propia exposición a CVE sin coste adicional. Los escáneres de vulnerabilidades no respetan los límites de los paquetes, y tampoco lo hace la cobertura de TuxCare. Se aborda toda la superficie de parcheo, no solo los paquetes de Kafka de nivel superior.
Proceso de aplicación de parches optimizado y automatizado: TuxCare supervisa el NVD, los avisos de seguridad de los proveedores, la propia lista CVE de Apache y los feeds de seguridad de GitHub, todos los canales en los que se revelan las vulnerabilidades de Kafka y sus dependencias. Cuando se identifica un CVE, las herramientas algorítmicas y la automatización asistida por IA se encargan de aplicar las correcciones de seguridad a la versión compatible, y los expertos en seguridad validan cada parche antes de su lanzamiento. Cada actualización se somete a pruebas de integridad, funcionalidad y regresión antes de llegar a sus repositorios. Para obtener todos los detalles técnicos, consulte el informe técnico de TuxCare sobre su proceso de aplicación de parches de código abierto.
Integración perfecta: Los paquetes ELS de TuxCare se integran directamente con Maven, Gradle y otras herramientas estándar de gestión de dependencias y compilación de Java que ya utilizan las implementaciones de Kafka. No hay cambios en su proceso de compilación, ni en sus flujos de trabajo de CI/CD, ni en la forma de trabajar de sus equipos. Puede pasar al repositorio seguro de TuxCare con cambios mínimos en la configuración, y las actualizaciones de seguridad se distribuyen automáticamente a través de su cadena de herramientas existente.
Respuesta rápida respaldada por un acuerdo de nivel de servicio (SLA): Cuando se revelan nuevas vulnerabilidades en versiones de Kafka fuera de ciclo de vida (EOL), ya sea en el propio broker o en su árbol de dependencias, TuxCare proporciona parches en un plazo garantizado respaldado por acuerdos de nivel de servicio. Las vulnerabilidades de gravedad alta y crítica (CVSS 7+) se resuelven en un plazo de 14 días desde su divulgación pública. No tendrá que esperar a una adaptación de la comunidad que nunca llegará para una versión de Apache Kafka fuera de ciclo de vida. Obtendrá parches listos para producción en un plazo que podrá planificar, con asistencia de expertos las 24 horas del día, los 7 días de la semana, para la clasificación de vulnerabilidades y la resolución de problemas.
Continuidad de la seguridad a un precio asequible: El coste de TuxCare ELS es una fracción de lo que cuesta una migración de clúster de emergencia cuando se ve obligada por un plazo de cumplimiento normativo en cuanto a tiempo de ingeniería, riesgo operativo, respuesta a incidentes y retrasos en el trabajo de la hoja de ruta. Una cobertura de seguridad predecible, un calendario de actualizaciones controlado y la ausencia de emergencias de cumplimiento normativo son los factores que hacen del soporte ampliado la estrategia de nivel empresarial para gestionar la exposición al fin de vida útil (EOL) de Apache Kafka.
Para ver exactamente qué vulnerabilidades se han solucionado en esas versiones fuera de soporte, TuxCare mantiene una rrastreador CVE actualizado para todas las tecnologías EOL compatibles.
No dejes que el fin de la vida útil de Apache Kafka ponga en riesgo tus flujos de datos
El fin de la vida útil (EOL) de Apache Kafka no significa que tu clúster quede comprometido de inmediato, ni que debas llevar a cabo una migración de emergencia para la que tus equipos no estén preparados. Sin embargo, sí significa que la cobertura de seguridad de la que dependía tu infraestructura de streaming ya no existe, y que ese vacío debe gestionarse de forma planificada.
Las organizaciones que gestionan bien esta situación son aquellas que abordan el fin de vida útil (EOL) de Apache Kafka como un problema de seguridad que hay que gestionar, y no como una fecha límite a la que reaccionar bajo presión. Puedes planificar una actualización meditada a una versión actual de Kafka cuando realmente se ajuste a la capacidad de tu equipo, incluyendo el tiempo adicional necesario para ejecutar correctamente la migración de ZooKeeper a KRaft y validar la compatibilidad de los clientes en todo tu ecosistema de canalización. Puedes evaluar si una migración de plataforma responde a un objetivo arquitectónico real. O puede utilizar TuxCare ELS para mantener la seguridad y el cumplimiento normativo al máximo mientras toma esas decisiones según su propio calendario, y no el de un auditor de cumplimiento.
El soporte ampliado no es una solución provisional. Es la opción que mantiene segura tu infraestructura de Kafka, garantiza el cumplimiento normativo y permite que tus equipos de ingeniería se centren en desarrollar, en lugar de en apagar incendios. Si el fin de la vida útil (EOL) de Apache Kafka figura actualmente entre tus prioridades de seguridad, visita el soporte de ciclo de vida ilimitado de TuxCare para software de código abierto para ver cómo el soporte ampliado puede proteger su infraestructura de streaming durante todo el tiempo que necesite.
