Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Apache Kafka constitue la colonne vertébrale de l'infrastructure de données en temps réel pour des milliers d'organisations à travers le monde. Son architecture à haut débit et tolérante aux pannes en a fait le choix incontournable pour la diffusion d'événements, les pipelines de données et la messagerie critique dans tous les secteurs, des services financiers au commerce électronique. Mais le rythme de publication soutenu de Kafka signifie que les fenêtres de prise en charge des versions se referment bien plus rapidement que ne le prévoient la plupart des équipes d'entreprise, et lorsqu'une date de fin de vie (EOL) d'Apache Kafka arrive, l'impact va bien au-delà du broker lui-même.
Cet article explique ce que signifie réellement la fin de vie de Kafka pour les équipes chargées de l'infrastructure de données, où se cache le véritable risque de sécurité, pourquoi la mise à niveau vers Kafka 4.0 est plus exigeante qu'une simple mise à jour de version classique, et comment le service « Endless Lifecycle Support » (ELS) de TuxCare vous permet de maintenir une couverture complète en matière de sécurité et de conformité sans imposer une mise à niveau pour laquelle vos équipes ne sont pas prêtes.
Principaux enseignements
- Les dépendances multiplient votre surface d'exposition aux menaces : Lorsqu'une version de Kafka arrive en fin de vie, vous êtes lié aux versions spécifiques des dépendances fournies avec celle-ci. Ces versions verrouillées finissent par dépasser leurs propres délais de prise en charge en amont au fil du temps, vous exposant ainsi à des vulnérabilités non corrigées sans possibilité de mise à niveau directe.
- Les mises à niveau précipitées sont coûteuses et risquées : Le passage de Kafka 3.x à 4.x nécessite une migration obligatoire de ZooKeeper vers KRaft, des mises à niveau de la version Java, des changements de compatibilité des API de protocole et la suppression de certains outils, autant d'éléments qui exigent une planification minutieuse et des tests approfondis, et non des délais serrés.
- La fin de vie (EOL) d'Apache Kafka ne signifie pas la fin de la sécurité : TuxCare ELS étend la couverture de sécurité à ces versions en fin de vie et à leurs arborescences de dépendances, permettant ainsi aux entreprises de maintenir la sécurité et la conformité tout en planifiant une mise à niveau réfléchie, dotée des ressources adéquates, selon leur propre calendrier.
En quoi consiste le cycle de vie du produit Apache Kafka ?
Kafka suit un calendrier de publication établi en 2016. La communauté publie une nouvelle version mineure tous les quatre mois environ, ce qui représente environ trois versions par an. Chaque version se voit attribuer une branche numérotée, par exemple 3.7, 3.8, 3.9, 4.0, avec son propre flux de correctifs.
La communauté assure le support des trois dernières versions mineures à tout moment, ce qui correspond à une période de support d'environ 12 à 16 mois par version. Kafka ne publie pas à l'avance de dates officielles de fin de vie ; une version atteint effectivement le statut de fin de vie (EOL) d'Apache Kafka lorsqu'elle disparaît de la liste des versions prises en charge sur la page de téléchargement officielle, à mesure que de nouvelles versions sont publiées. Concrètement, cela signifie que tous les quatre mois, une version perd le support de la communauté sans préavis officiel.
Calendrier actuel de prise en charge des versions de Kafka :
| Version | Date de sortie | Date de fin de vie | Statut |
| Kafka 3.7 | Février 2024 | Juillet 2024 | EOL |
| Kafka 3.8 | Juillet 2024 | Novembre 2024 | EOL |
| Kafka 3.9 | Novembre 2024 | Mi-2026 | Actif |
| Kafka 4.0 | Mars 2025 | Juillet 2026 | Actif |
| Kafka 4.1 | Septembre 2025 | Novembre 2026 | Actif |
| Kafka 4.2 | Février 2026 | Mai 2027 | Actif |
Remarque : Kafka ne publie pas de dates officielles de fin de vie. Ces délais sont calculés à partir de la politique de prise en charge de trois versions consécutives adoptée par la communauté et d'intervalles de publication d'environ quatre mois.
Ce rythme est soutenu par rapport aux normes en vigueur dans le monde de l'entreprise. Les organisations opérant dans des secteurs réglementés ou gérant des infrastructures complexes de pipelines de données, où les mises à niveau nécessitent de longs cycles de validation, se retrouvent régulièrement à utiliser des versions dont la date de fin de vie a été discrètement dépassée avant que la mise à niveau prévue ne soit prête à être effectuée.
Quelles sont les implications de la fin de vie d'Apache Kafka pour l'infrastructure de données ?
Pour un simple serveur d'applications, la fin de vie signifie simplement que le système ne reçoit plus de correctifs. Pour les organisations qui utilisent Kafka comme système nerveux central de leur infrastructure de données, reliant producteurs, consommateurs, pipelines Kafka Connect, applications Kafka Streams et systèmes d'analyse en aval, la situation est fondamentalement différente et nettement plus complexe.
Plus aucun correctif de sécurité après la date de fin de vie
Une fois qu'une version de Kafka arrive en fin de vie, la communauté Apache cesse de publier des correctifs de sécurité pour celle-ci. Toute vulnérabilité signalée après la date de fin de vie, qu'elle concerne le broker lui-même, le worker Kafka Connect ou les bibliothèques clientes, ne fera pas l'objet d'un correctif officiel pour cette version. La seule solution proposée par la communauté consiste à passer à une version prise en charge.
Pour les équipes qui gèrent de grands clusters Kafka critiques pour la production, où les mises à niveau nécessitent des tests approfondis, une validation coordonnée des pipelines et un déploiement minutieusement planifié, cela n'est pas toujours possible dans des délais très courts. C'est précisément pendant le laps de temps qui s'écoule entre la date d'entrée en vigueur de la fin de vie (EOL) et le moment où une mise à niveau peut être raisonnablement menée à bien et validée que les vulnérabilités non corrigées s'accumulent.
Risques liés à la sécurité et à la conformité après la fin de vie
Les conséquences en matière de conformité liées à l'utilisation d'une version de Kafka en fin de vie sont directes. La norme PCI DSS (exigence 6.3.3) impose l'installation des correctifs critiques et à haut niveau de gravité dans un délai d'un mois à compter de leur publication ; or, sur une version d'Apache Kafka en fin de vie, il n'existe aucun correctif à installer, ce qui rend impossible la mise en conformité par les moyens habituels. Les auditeurs SOC 2 signalent les logiciels en fin de vie dans les environnements de production. L'utilisation d'un cluster Kafka sur une version non prise en charge crée des lacunes dans la documentation qui apparaissent dans les questionnaires de sécurité, retardent les certifications des fournisseurs et, dans les secteurs réglementés, bloquent les renouvellements de contrats avec les clients.
Pour les organisations dans lesquelles Kafka relève du champ d'application de la norme PCI, traite des données à caractère personnel ou sous-tend des services soumis à des obligations contractuelles en matière de SLA, le risque de non-conformité lié à cette fin de vie n'est pas qu'une hypothèse théorique. Il s'agit d'un constat d'audit qui ne demande qu'à se concrétiser.
Historique des CVE : ce que révèle le registre des vulnérabilités
L'historique des vulnérabilités CVE de Kafka illustre bien le type de failles qui ne sont plus jamais corrigées sur les versions en fin de vie.
CVE-2023-25194 (NVD CVSS 3.1 : 8,8 – Risque élevé) a révélé une vulnérabilité permettant l'exécution de code à distance et un vecteur de déni de service dans Kafka Connect. En configurant les propriétés SASL JAAS du client Kafka d'un connecteur pour qu'elles pointent vers un serveur LDAP malveillant, un opérateur authentifié pouvait déclencher la désérialisation de données non fiables sur le nœud de travail Connect, permettant ainsi l'exécution de code arbitraire si des gadgets étaient disponibles dans le classpath. Cela a affecté les clusters Kafka depuis la version 2.3.0, et le problème était suffisamment grave pour générer des bulletins de sécurité de la part d'IBM concernant plusieurs produits, notamment IBM Maximo Application Suite et IBM Business Automation Workflow. Le correctif nécessitait une mise à niveau vers des versions corrigées ; les anciennes versions en fin de vie exécutant Kafka Connect restaient exposées sans qu'aucune solution officielle ne soit disponible.
CVE-2025-27819 (NVD CVSS 3.1 : 7,5 Élevé) fait suite à CVE-2023-25194, révélant que la même vulnérabilité SASL JAAS JndiLoginModule existait dans les brokers Kafka, et pas seulement dans Kafka Connect, affectant les versions 2.0.0 à 3.3.2. L'attaque nécessite un accès réseau au cluster et l'autorisation AlterConfigs sur la ressource du cluster. Une exploitation réussie permet à un attaquant de déclencher des connexions arbitraires vers un serveur LDAP contrôlé par l'attaquant et de provoquer des conditions de déni de service. Elle a été rendue publique en juin 2025, et le correctif désactivant par défaut les modules de connexion problématiques n'a été fourni que dans les versions 3.9.1 et 4.0.0. Les branches en fin de vie n'ont reçu aucune mise à jour.
Il s'agit précisément de la catégorie de vecteurs d'exploitation RCE (exécution de code à distance) sur des systèmes authentifiés au sein de l'infrastructure centrale de Kafka, dont la correction nécessite une mise à jour de version, ce qui se traduit par une faille de sécurité qui reste irrémédiable sur les versions en fin de vie.
Le risque caché : l'arbre de dépendances de Kafka
La surface d'exposition d'un déploiement Kafka ne se limite pas au binaire du broker. Kafka s'accompagne d'un ensemble considérable de dépendances qui comportent leurs propres risques de sécurité. Lorsque Kafka arrive en fin de vie, le problème n'est pas que ces projets en amont cessent de fournir des correctifs. Le problème réside dans le fait que vous êtes prisonnier des versions spécifiques des dépendances auxquelles la version Kafka en fin de vie a été verrouillée, et que ces versions verrouillées finissent par dépasser leurs propres délais de support en amont au fil du temps.
À elle seule, la bibliothèque kafka-clients intègre des dépendances de compression, notamment snappy-java, LZ4-java et zstd-jni. Le broker et Kafka Connect intègrent Jackson Databind et les modules Jackson associés pour le traitement JSON, Netty pour le transport réseau, ainsi que slf4j avec Log4j2 pour la journalisation. Les versions antérieures de Kafka s'appuyaient sur Apache ZooKeeper, un projet qui possède son propre historique de vulnérabilités CVE, pour la gestion des métadonnées du cluster. Les outils du broker incluent RocksDB pour les magasins d'état de Kafka Streams, et la bibliothèque standard complète de Scala est fournie en tant que dépendance d'exécution.
Chacune de ces dépendances est associée à son propre flux CVE en amont. La bibliothèque snappy-java, par exemple, a été directement impliquée dans la faille CVE-2023-34455 (NVD CVSS 3.1 : 7,5 Élevé), une vulnérabilité de déni de service affectant les versions 0.8.0 à 3.5.0 de Kafka, dans laquelle une charge utile malveillante compressée avec snappy-java pouvait amener les brokers à allouer des quantités arbitrairement importantes de mémoire heap, entraînant une exception OutOfMemoryException et un déni de service à l'échelle du cluster. Jackson Databind a généré des dizaines de CVE de gravité élevée au cours de son histoire, liées à une désérialisation non sécurisée. Netty a lui aussi un historique de vulnérabilités au niveau de la couche réseau.
Lorsqu'une version de Kafka atteint le statut EOL, vous ne recevez plus les mises à jour de Kafka qui actualisent ces versions de dépendances pour vous. Vous restez bloqué sur les versions auxquelles la version EOL de Kafka est liée, et ces versions spécifiques peuvent également finir par ne plus recevoir les correctifs rétroportés de leurs propres projets en amont. Le résultat est le même : les scanners de vulnérabilité exécutés sur des déploiements Kafka en fin de vie (EOL) génèrent des résultats dans l'arborescence des dépendances pour lesquels il n'existe pas de voie de correction directe, laissant les équipes de sécurité face à une liste croissante de résultats d'analyse non résolubles et sans chemin de mise à niveau pris en charge au sein de la version EOL.
Solutions pour garantir la sécurité et la conformité
Les organisations qui utilisent des versions d'Apache Kafka arrivées en fin de vie (EOL) ont deux options. La première implique un effort technique considérable, des risques opérationnels et des délais prolongés. La seconde, le service « Endless Lifecycle Support » de TuxCare, comble immédiatement les failles de sécurité.
Option 1 : Passer à la version actuelle de Kafka
La solution à long terme consiste à mettre à niveau le cluster Kafka vers une version actuellement prise en charge. Les versions actuellement prises en charge de manière active sont Kafka 3.9, 4.0, 4.1 et 4.2, chacune bénéficiant d'une couverture continue en matière de correctifs.
En pratique, notamment pour la transition de la version 3.x à la version 4.x, il s'agit de l'une des mises à niveau les plus exigeantes de l'histoire de Kafka. Kafka 4.0 supprime complètement la prise en charge de ZooKeeper ; les clusters fonctionnant encore en mode ZooKeeper doivent effectuer la migration des métadonnées de ZooKeeper vers KRaft avant de pouvoir passer à la version 4.0 ou à toute version ultérieure. Pour les clusters fonctionnant sous des versions plus anciennes de Kafka, le chemin de migration peut nécessiter plusieurs étapes intermédiaires : mise à niveau vers la version 3.4, mise à niveau de ZooKeeper vers la version 3.8, mise à niveau vers la version 3.9, exécution de la migration des métadonnées de ZooKeeper vers KRaft, puis passage à la version 4.0. Kafka 4.0 abandonne également complètement la prise en charge de Java 8 et nécessite Java 17 pour les brokers et les outils, supprime MirrorMaker 1 sans chemin de migration sur place, supprime les versions obsolètes de l'API du protocole client et supprime l'API transformValues() de Kafka Streams. Chacun de ces changements doit être pris en compte avant de pouvoir procéder à la mise à niveau. Pour les organisations exploitant de vastes parcs Kafka prenant en charge plusieurs équipes et pipelines, une mise à niveau vers la version 4.x correctement planifiée se mesure en mois, et non en semaines.
Option 2 : Assistance TuxCare pour un cycle de vie prolongé : la solution recommandée
C'est la solution qui résout le problème immédiat sans en créer de nouveaux. Le service « Endless Lifecycle Support » de TuxCare pour Kafka vous permet de continuer à utiliser votre version actuelle de Kafka en production tout en bénéficiant d'une couverture continue des correctifs de sécurité pour le broker et son arbre de dépendances, fournie via votre chaîne d'outils existante, sans aucune migration obligatoire.
La faille de sécurité est immédiatement comblée. Votre conformité est préservée. Vos équipes sont libres de planifier la mise à niveau appropriée selon un calendrier opérationnel raisonnable, y compris le délai supplémentaire nécessaire pour effectuer correctement la migration de ZooKeeper vers KRaft, valider la compatibilité des versions Java sur l'ensemble de votre pile applicative et coordonner le déploiement sur tous les services producteurs et consommateurs qui dépendent de votre cluster Kafka. Pas de mise à niveau forcée sous la pression d'une échéance, pas d'urgence de conformité, pas de problèmes de compatibilité dans l'infrastructure de production qui sous-tend les pipelines de données en direct.
Les risques liés à une mise à niveau précipitée de Kafka
Lorsqu'un statut « fin de vie » apparaît sur un tableau de bord de sécurité et que l'équipe chargée de la conformité commence à poser des questions, la pression pour agir immédiatement est bien réelle. Il est tout aussi important de comprendre ce qu'implique réellement une mise à niveau précipitée de Kafka que de cerner le risque lui-même.
En quoi consiste réellement une mise à niveau vers Kafka ?
Une mise à niveau correcte de Kafka, en particulier de la version 3.x à la version 4.x, est un projet d'infrastructure en plusieurs phases, et non une simple mise à jour de version. Elle nécessite de planifier le chemin de mise à niveau en fonction de votre version actuelle et de votre mode de métadonnées, d'exécuter toutes les mises à niveau intermédiaires requises, de mener à bien la migration de ZooKeeper vers KRaft le cas échéant, d'effectuer des redémarrages progressifs des brokers à travers le cluster, de vérifier que toutes les applications clientes restent compatibles avec la nouvelle version des brokers, de s'assurer que tous les connecteurs Kafka Connect fonctionnent correctement sur le cluster mis à jour, de tester les applications Kafka Streams face à d'éventuelles modifications de l'API, et d'exécuter des déploiements coordonnés à travers les environnements de développement, de préproduction et de production.
Adaptation du code : Kafka 4.0 supprime les API obsolètes, notamment transformValues() dans Kafka Streams et les anciennes versions de l'API de protocole. Les applications utilisant des API supprimées doivent être mises à jour avant de pouvoir procéder à la mise à niveau du cluster.
Vérification de la compatibilité : Chaque producteur, consommateur, connecteur Kafka Connect et application Kafka Streams de l'écosystème doit être vérifié par rapport à la version cible de Kafka. Un seul client ou connecteur incompatible peut entraîner des défaillances du pipeline de données qui affectent les systèmes en aval.
Adaptation de la chaîne d'outils : les pipelines CI/CD, les scripts de déploiement, les configurations de surveillance et les définitions d'infrastructure en tant que code qui font référence à des configurations spécifiques à Kafka doivent être revus et mis à jour, en particulier pour les modifications de configuration KRaft qui regroupent le répertoire kraft/config dans le répertoire de configuration principal dans la version 4.0.
Charge liée aux tests : Les tests d'intégration complets couvrant l'ensemble du pipeline, des producteurs aux consommateurs en passant par les intermédiaires, ne peuvent être ignorés. Les modifications du comportement de rééquilibrage, les nouvelles implémentations de coordinateurs de groupe et les changements de version du protocole doivent tous être validés sous une charge réaliste avant le déploiement en production.
Que se passe-t-il lorsqu'une mise à niveau est précipitée ?
Lorsque les équipes doivent réaliser ce travail dans l'urgence pour respecter les délais, les conséquences sont prévisibles et suivent un schéma récurrent.
Augmentation de la charge de support : les problèmes de compatibilité non détectés lors des tests intensifs apparaissent en production. Les pics de latence pour les utilisateurs, les défaillances de connecteurs et les comportements de rééquilibrage inattendus génèrent une vague d'incidents que les équipes d'ingénierie et d'exploitation doivent gérer en plus de leur charge de travail habituelle.
Instabilité du système : Les clusters Kafka sous-tendent les pipelines de données dont dépendent les systèmes en aval. Des changements de comportement subtils induits par une mise à niveau au niveau de l'attribution des partitions, de la coordination des groupes de consommateurs et de la gestion du magasin d'état de Kafka Streams peuvent provoquer des défaillances intermittentes difficiles à reproduire et qui se manifestent avec des volumes de données en production que les environnements de préproduction atteignent rarement.
Accumulation de la dette technique : les solutions de contournement mises en place sous la pression du temps deviennent permanentes. Les applications sont adaptées à la hâte pour passer les contrôles de compatibilité, plutôt que d'accumuler correctement les hypothèses qui posent des problèmes pour le prochain cycle de mise à niveau. Le problème de fin de vie (EOL) d'Apache Kafka est reporté, mais pas résolu.
Coûts imprévus : les heures d'intervention d'urgence des ingénieurs, les retards dans la mise en production des fonctionnalités, les frais généraux liés à la gestion des incidents, ainsi que le coût d'opportunité lié au fait que des ingénieurs de données seniors doivent déboguer les défaillances du pipeline de production au lieu de développer de nouvelles fonctionnalités : tous ces éléments s'accumulent rapidement et de manière difficile à prévoir à l'avance.
La solution simple : TuxCare ELS pour Apache Kafka en fin de vie
TuxCare offre une assistance tout au long du cycle de vie pour les versions de Kafka en fin de vie. Au lieu d'imposer une mise à niveau du cluster pour laquelle vos équipes ne sont pas encore prêtes, vous continuez à exploiter votre déploiement actuel en fin de vie tout en bénéficiant d'une couverture continue des correctifs de sécurité via votre chaîne d'outils de compilation et de déploiement existante.
TuxCare s'y emploie depuis plus de dix ans, en fournissant des correctifs de sécurité pour les systèmes d'exploitation, les environnements d'exécution, les bibliothèques et les frameworks d'applications en fin de vie. L'entreprise a distribué plus de 220 000 correctifs de sécurité à travers l'écosystème open source. Lorsqu'elle affirme savoir comment assurer la sécurité des versions en fin de vie à l'échelle de l'entreprise, ce ne sont pas de simples promesses marketing. Elle l'a prouvé à grande échelle, de manière constante.
Couverture complète de l'arborescence des dépendances : L'ELS de TuxCare pour Apache Kafka couvre le broker et ses dépendances directes et transitives, y compris snappy-java, Jackson Databind, Netty et d'autres bibliothèques qui présentent leurs propres expositions CVE, sans frais supplémentaires. Les scanners de vulnérabilité ne respectent pas les limites des paquets, et la couverture de TuxCare non plus. L'ensemble de la surface de correction est pris en compte, et pas seulement les paquets Kafka de niveau supérieur.
Processus de correction optimisé et automatisé : TuxCare surveille le NVD, les avis de sécurité des fournisseurs, la liste CVE d’Apache et les flux de sécurité GitHub, soit tous les canaux par lesquels les vulnérabilités de Kafka et de ses dépendances sont divulguées. Lorsqu’un CVE est identifié, des outils algorithmiques et une automatisation assistée par l’IA se chargent de rétroporter les correctifs de sécurité vers la version prise en charge, et des experts en sécurité valident chaque correctif avant sa publication. Chaque mise à jour est soumise à des tests d’intégrité, de fonctionnalité et de régression avant d’atteindre vos référentiels. Pour plus de détails techniques, consultez le livre blanc technique de TuxCare sur son processus de correction open source.
Intégration transparente : Les packages ELS de TuxCare s'intègrent directement à Maven, Gradle et aux autres outils standard de gestion des dépendances et de build Java déjà utilisés pour les déploiements Kafka. Aucune modification n'est nécessaire au niveau de votre pipeline de build, de vos workflows CI/CD ou des méthodes de travail de vos équipes. Vous passez au référentiel sécurisé de TuxCare avec un minimum de modifications de configuration, et les mises à jour de sécurité sont automatiquement intégrées à votre chaîne d'outils existante.
Intervention rapide garantie par un accord de niveau de service (SLA) : Lorsque de nouvelles vulnérabilités sont révélées dans les versions EOL de Kafka, que ce soit au niveau du broker lui-même ou de son arbre de dépendances, TuxCare fournit des correctifs dans des délais garantis, soutenus par des accords de niveau de service. Les vulnérabilités de gravité élevée et critique (CVSS 7+) sont traitées dans les 14 jours suivant leur divulgation publique. Vous n'avez pas à attendre un backport de la communauté qui ne viendra jamais pour une version Apache Kafka en fin de vie. Vous bénéficiez de correctifs prêts à l'emploi selon un calendrier prévisible, avec une assistance d'experts 24 h/24 et 7 j/7 pour le triage des vulnérabilités et le dépannage.
Une continuité de la sécurité à moindre coût : Le coût de TuxCare ELS ne représente qu'une fraction de ce que coûte une migration de cluster en urgence, imposée par une échéance de conformité, en termes de temps d'ingénierie, de risque opérationnel, de réponse aux incidents et de retard dans la feuille de route. Une couverture de sécurité prévisible, un calendrier de mise à niveau maîtrisé et l'absence d'urgences de conformité font du support étendu la stratégie de niveau entreprise pour gérer l'exposition à la fin de vie (EOL) d'Apache Kafka.
Pour savoir précisément quelles vulnérabilités ont été corrigées pour ces versions en fin de vie, TuxCare tient à jour une suivisuivi CVE en temps réel pour toutes les technologies en fin de vie prises en charge.
Ne laissez pas la fin de vie d'Apache Kafka mettre vos pipelines de données en danger
La fin de vie d'Apache Kafka ne signifie pas que votre cluster est immédiatement compromis, ni que vous devez procéder à une migration d'urgence pour laquelle vos équipes ne sont pas préparées. Cela signifie toutefois que la protection de sécurité sur laquelle reposait votre infrastructure de streaming n'est plus assurée, et que cette lacune doit être gérée de manière réfléchie.
Les organisations qui gèrent bien cette situation sont celles qui considèrent la fin de vie d'Apache Kafka comme un problème de sécurité à gérer, et non comme une échéance à laquelle il faut réagir sous la pression. Vous pouvez planifier une mise à niveau réfléchie vers une version actuelle de Kafka lorsque cela correspond réellement aux capacités de votre équipe, en tenant compte du temps supplémentaire nécessaire pour effectuer correctement la migration de ZooKeeper vers KRaft et pour valider la compatibilité des clients dans l'ensemble de votre écosystème de pipeline. Vous pouvez évaluer si une migration de plateforme répond à un véritable besoin architectural. Ou vous pouvez utiliser TuxCare ELS pour maintenir une sécurité et une conformité totales tout en prenant ces décisions selon votre propre calendrier, et non celui d'un auditeur de conformité.
Le support prolongé n'est pas une solution de fortune. C'est l'option qui garantit la sécurité de votre infrastructure Kafka, préserve votre conformité et permet à vos équipes d'ingénieurs de se concentrer sur le développement plutôt que sur la gestion des urgences. Si la fin de vie d'Apache Kafka figure actuellement parmi vos priorités en matière de sécurité, rendez-vous sur le support à cycle de vie illimité de TuxCare pour les logiciels open source pour découvrir comment le support étendu peut protéger votre infrastructure de streaming aussi longtemps que vous en avez besoin.
