Le streaming de données est apparu comme une nouvelle catégorie de logiciels. Il complète le middleware traditionnel, l’entrepôt de données et les lacs de données. Apache Kafka est devenu la norme de facto. De nouveaux acteurs entrent sur le marché en raison du succès de Kafka. L’un d’entre eux est Redpanda, une implémentation C++ légère compatible avec Kafka. Cet article explore les différences entre Apache Kafka et Redpanda, quand choisir quel framework et comment l’écosystème Kafka, les licences et l’adoption par la communauté ont un impact sur une évaluation appropriée.
Streaming de données : une nouvelle catégorie de logiciels
Les applications basées sur les données sont le nouveau noir. Dans ce cadre, le streaming de données est une nouvelle catégorie de logiciels. Si vous ne comprenez pas encore en quoi elle diffère des autres plates-formes de gestion de données telles qu’un entrepôt de données ou un lac de données, consultez la série d’articles suivante :
- Data Warehouse vs Data Lake vs Data Streaming – Amis, Ennemis, Frenemies ?
- Diffusion de données pour l’ingestion de données dans l’entrepôt de données et le lac de données
- Modernisation de l’entrepôt de données : de l’ancienne infrastructure sur site à l’infrastructure cloud native
- Études de cas : diffusion de données native dans le cloud pour la modernisation de l’entrepôt de données
Apache Kafka : la norme de facto pour le streaming de données
Apache Kafka est devenu la norme de facto pour le streaming de données similaire à Amazon S3 est la norme de facto pour le stockage d’objets. Kafka est utilisé dans de nombreux secteurs d’activité pour de nombreux cas d’utilisation.
La courbe d’adoption d’Apache Kafka
La croissance de la communauté Apache Kafka ces dernières années est impressionnante :
- >100 000 organisations utilisant Apache Kafka
- >41 000 participants à la rencontre Kafka
- > 32 000 questions sur le débordement de pile
- >12 000 Jiras pour Apache Kafka
- >31 000 offres d’emploi ouvertes demandent des compétences Kafka
Regardez l’augmentation du nombre d’utilisateurs uniques mensuels actifs téléchargeant la bibliothèque client Kafka Java avec Maven :
Source: Sonatype
Les chiffres augmentent de façon exponentielle. Cela ne me surprend pas car le modèle d’adoption et la courbe de maturité de Kafka sont similaires dans la plupart des entreprises :
- Commencez par un ou quelques cas d’utilisation (qui prouvent rapidement la valeur commerciale).
- Déployez les premières applications en production et exploitez-les 24h/24 et 7j/7.
- Exploitez les flux de données de nombreux domaines, unités commerciales et technologies.
- Passez à un système nerveux central stratégique avec un hub de données décentralisé.
Cas d’utilisation de Kafka par valeur commerciale dans tous les secteurs
La principale raison de l’incroyable croissance de la courbe d’adoption de Kafka est la variété des cas d’utilisation potentiels pour le streaming de données. Le potentiel est presque infini. Les caractéristiques de Kafka consistant à combiner faible latence, évolutivité, fiabilité et véritable découplage, établissent des avantages dans tous les secteurs et cas d’utilisation :
L’émergence de nombreux vendeurs de Kafka
Le marché du streaming de données est énorme. Avec autant de cas d’utilisation potentiels, il n’est pas surprenant que de plus en plus d’éditeurs de logiciels ajoutent la prise en charge de Kafka à leurs produits. La plupart des fournisseurs utilisent Kafka ou implémentent son protocole car Kafka est devenu la norme de facto pour le streaming de données.
Pour être clair : un nombre croissant de vendeurs de Kafka est une bonne chose ! Cela prouve la création d’une nouvelle catégorie de logiciels. La concurrence pousse l’innovation. La part de marché est assez importante pour de nombreux fournisseurs. Et, je suis convaincu à 100 % que nous sommes encore à un stade très précoce du cycle de battage médiatique du streaming de données…
Après une longue introduction pour situer le contexte, passons en revue un nouvel entrant sur le marché de Kafka : Redpanda.
Présentation de Redpanda : diffusion de données compatible avec Kafka
Redpanda est une plateforme de streaming de données. Son site explique son positionnement sur le marché et sa stratégie produit comme suit (pour le différencier d’Apache Kafka) :
- pas Java: Une infrastructure sans JVM et sans ZooKeeper.
- Conçu en C++: Conçu pour une meilleure performance qu’Apache Kafka.
- Une architecture mono-binaire: Aucune dépendance à d’autres bibliothèques ou nœuds.
- Autogestion et auto-guérison: Une architecture simple mais évolutive pour les déploiements sur site et dans le cloud.
- Compatible avec Kafka: Prise en charge prête à l’emploi du protocole Kafka avec les applications, outils et intégrations existants.
Cela sonne bien. Vous devez évaluer si Redpanda est le bon choix pour votre prochain projet ou si vous devez vous en tenir au « vrai Apache Kafka ».
Comment choisir la bonne implémentation « Kafka » pour votre projet
Une recommandation que certaines personnes trouvent surprenante : Qualifiez-vous en premier ! C’est beaucoup plus facile. De même, comme je l’ai expliqué quand NE PAS utiliser Apache Kafka.
Dans le cadre de l’évaluation, la question est de savoir si Kafka est le bon protocole pour vous. Et pour Kafka, choisissez différentes offres et commencez par la comparaison.
Commencez votre évaluation avec les exigences de l’analyse de rentabilisation et définissez vos besoins les plus critiques tels que les SLA de disponibilité, la stratégie de reprise après sinistre, le support d’entreprise, les outils d’exploitation, le service cloud autogéré ou entièrement géré, les fonctionnalités telles que la messagerie, l’ingestion de données et l’intégration de données. vs applications, et ainsi de suite. En fonction de vos cas d’utilisation et de vos exigences, vous pouvez commencer à qualifier des fournisseurs tels que Confluent, Redpanda, Cloudera, Red Hat / IBM, Amazon MSK, Amazon Kinesis, Google Pub Sub et d’autres pour créer une liste restreinte.
Les sections suivantes comparent le projet open source Apache Kafka à la réimplémentation du protocole Kafka de Redpanda. Vous pouvez utiliser ces critères (et les informations d’autres blogs, articles, vidéos, etc.) pour évaluer vos options.
Similitudes entre Redpanda et Apache Kafka
Les propositions de valeur de haut niveau sont les mêmes dans Redpanda et Apache Kafka :
- Flux de données pour traiter les données en temps réel à grande échelle en continu.
- Découplez les applications et les domaines avec une couche de stockage distribuée.
- Intégration avec diverses sources de données et puits de données.
- Tirez parti du traitement de flux pour corréler les données et prendre des mesures en temps réel.
- Opérations autogérées ou utilisation d’une offre cloud entièrement gérée.
Cependant, le diable est dans les détails et les faits. Ne faites pas confiance au marketing, mais examinez plus en profondeur les différents produits et services cloud.
Options de déploiement : autogéré ou service cloud
Le streaming de données est requis partout. Alors que la plupart des entreprises de tous les secteurs ont une stratégie axée sur le cloud, certaines charges de travail doivent rester à la périphérie pour différentes raisons : coût, latence ou exigences de sécurité.
En plus d’exploiter Redpanda par vous-même, vous pouvez acheter Redpanda en tant que produit et le déployer dans votre environnement. Au lieu d’auto-héberger Redpanda, vous pouvez le déployer en tant que plan de données dans votre environnement à l’aide de Kubernetes (pris en charge par le plan de contrôle externe du fournisseur) ou tirer parti d’un service cloud (entièrement géré par le fournisseur).
Les différentes options de déploiement pour Redpanda sont excellentes. Choisissez ce dont vous avez besoin. Ceci est très similaire aux options de déploiement de Confluent pour Apache Kafka. Certains autres fournisseurs de Kafka ne proposent que des options de déploiement autogéré (par exemple, Cloudera) ou entièrement géré (par exemple, Amazon MSK Serverless).
Ce qui me manque de Redpanda : Aucune documentation officielle sur les SLA du service cloud et du support d’entreprise. J’espère qu’ils font mieux qu’Amazon MSK (à l’exclusion du support Kafka de leurs offres cloud). Je suis sûr que vous obtiendrez ces informations si vous contactez l’équipe de Redpanda, qui intégrera probablement bientôt des informations sur son site Web.
Apportez votre propre cluster (BYOC)
Outre l’autogestion d’un cluster de streaming de données et l’utilisation d’un service cloud entièrement géré, il existe une troisième option : apportez votre propre cluster (BYOC). Cette alternative permet aux utilisateurs finaux de déployer une solution partiellement gérée par le fournisseur dans votre propre infrastructure (comme votre centre de données ou votre VPC cloud).
Voici le slogan marketing de Redpanda : « Des clusters Redpanda hébergés sur votre cloud, entièrement gérés par Redpanda, afin que vos données ne quittent jamais votre environnement. »
Cela semble très attrayant en théorie. Malheureusement, cela crée plus de questions et de problèmes qu’il n’en résout :
- Comment le fournisseur accède-t-il à votre centre de données ou VPC ?
- Qui décide comment et quand faire évoluer un cluster ?
- Quand agir sur les problèmes ?
- Comment et quand déployer un cluster pour intégrer des corrections de bogues ou des mises à niveau de version ?
- Qu’en est-il de la gestion des coûts ?
- Quel est le coût total de possession ?
- Quelle valeur apporte la solution du fournisseur ?
- Comment garantissez-vous les SLA ?
- Qui doit les garantir, vous ou le vendeur ?
- Pour les industries réglementées, comment les contrôles de sécurité et la conformité sont-ils pris en charge ?
- Comment êtes-vous sûr de ce que fait le fournisseur dans un environnement que vous contrôlez ostensiblement ?
- À quel point une évaluation des risques sur mesure par un tiers sera-t-elle plus difficile si vous n’utilisez pas de SaaS pur ?
Pour ces raisons, les fournisseurs de cloud hébergent uniquement des services gérés dans l’environnement du fournisseur de cloud. Regardez Amazon MSK, Azure Event Hubs, Google Pub Sub, Confluent Cloud, etc. Tous les services cloud entièrement gérés se trouvent uniquement dans le VPC du fournisseur pour les raisons ci-dessus.
Il n’y a que deux options : soit vous confiez la responsabilité à une offre SaaS, soit vous la contrôlez vous-même. Tout ce qui se trouve au milieu est toujours votre responsabilité à la fin.
Offres communautaires vs offres commerciales
L’approche commerciale de Redpanda semble presque identique à la façon dont Confluent vend le streaming de données. Une édition communautaire gratuite est disponible, même pour une utilisation en production. L’édition entreprise ajoute des fonctionnalités d’entreprise telles que le stockage hiérarchisé, l’équilibrage automatique des données ou l’assistance aux entreprises 24h/24 et 7j/7.
Pas de surprise ici. Et une bonne stratégie, car le streaming de données est requis partout pour différents utilisateurs et acheteurs.
Différences techniques entre Apache Kafka et Redpanda
Il existe de nombreuses différences techniques et non fonctionnelles entre les produits Apache Kafka et Redpanda. Gardez à l’esprit que Redpanda n’est PAS Kafka. Redpanda utilise le protocole Kafka. C’est une petite mais critique différence. Explorons ces détails dans les sections suivantes.
Compatibilité entre Apache Kafka et le protocole Kafka
Redpanda n’est PAS une distribution Apache Kafka comme Confluent Platform, Cloudera ou Red Hat. Au lieu de cela, Redpanda réimplémente le protocole Kafka pour fournir une compatibilité API. Être compatible avec Kafka n’est pas la même chose qu’utiliser Apache Kafka sous le capot, même si cela sonne bien dans…