DataStax lance Astra Streaming, une version managée d’Apache Pulsar

Astra Streaming, « complément naturel » à AstraDB

Astra Streaming reprend l’offre de Kesque, c’est-à-dire une version entièrement managée de Pulsar. L’éditeur a prévu de décomissionner « Pulsar as a Service » et de migrer les clients de la startup vers sa solution. Tout comme Luna, Astra Streaming supporte les intégrations avec Elastic, Kafka (via un wrapper open source) et Java Message Service. Le spécialiste de Cassandra y a ajouté une interface utilisateur pour déployer rapidement un tenant et des topics.

DataStax positionne Astra Streaming comme « un complément naturel à AstraDB ». Les dirigeants évoquent notamment la possibilité d’utiliser la technologie pour opérer des capacités de « change data capture », c’est-à-dire le remplacement de données à la volée dans un SGBD.

 Mais l’éditeur vante surtout des capacités élastiques, de multitenant et de déploiements sur AWS, GCP ou Azure. Astra Streaming doit assurer des communications asynchrones entre les services et répondre aux cas d’usage les plus demandeurs comme l’analytique en temps réel, l’IoT, les intégrations complexes liées aux « expériences digitales » et l’injection de machine learning dans le système de traitement d’événements.

En outre, l’éditeur promet un modèle économique « accessible au mid-market », même s’il vise les acteurs du Fortune 10.

Au moment de l’acquisition de Kesque, Matt Aslett, directeur de recherche chez le cabinet S&P Global Market Intelligence expliquait à nos confrères de SearchDataManagement [Propriété de Techtarget, également propriétaire du MagIT] qu’il observait « un intérêt croissant pour Apache Pulsar […] grâce à l’étendue et à la richesse de ses fonctionnalités ».

Selon une enquête de StreamNative, un concurrent de DataStax, le nombre de contributeurs actifs sur les dépôts de GitHub sur Pulsar aurait dépassé ceux de Kafka.

DataStax remet une pièce dans le débat Pulsar vs Kafka

À ce jeu, DataStax veut concurrencer Confluent et tous les distributeurs d’Apache Kafka, le système de messagerie le plus largement utilisé par le Fortune 500, selon Confluent. Même, il affirme sans rougir qu’il peut mettre à l’amende les autres systèmes Pub/Sub du marché. Pour le prouver, il fait appel au service de GigaOm, un « blog » spécialisé dans le benchmarking de produits IT. Ici, GigaOm compare Luna Streaming et Kafka déployés sur des instances pratiquement identiques sur AWS. « Avec neuf nœuds de broker, Luna a atteint une moyenne de 306 Mo/s, alors que Kafka n’a atteint que 210 Mo/s », écrivent les testeurs de GigaOm.

Ils en viennent à la conclusion que les performances de 9 nœuds de broker Luna Streaming valent 14 nœuds de leur Kafka self-managed. Dans cette configuration, le benchmark considère que le déploiement de Kafka pèse 111 413 dollars par an contre 77 001 dollars pour Luna Streaming, soit une différence de 31 %. En compilant tous les tests et suivant les scénarios, GigaOm établit que Lunar Streaming coûte 19 à 81 % moins cher qu’un déploiement maison de Kafka sur EC2. Pour autant, les auteurs du benchmark mettent l’accent sur les cas d’usage les plus demandeurs et n’évoquent pas les performances d’Astra Streaming.

Ces résultats, GigaOm les explique par les différences d’architecture entre Pulsar et Kafka, le second étant considéré comme vieillissant.

De son côté, Confluent n’a pas attendu ce genre de démonstration pour faire ses propres évaluations. L’éditeur affirme haut et fort que Kafka offre un débit deux fois supérieur à Pulsar, suivant le framework OpenMessaging Benchmark (OMB, aussi utilisé par GigaOM) et une latence de 5 ms contre 25 ms pour une charge de 200 Mb/s. L’éditeur a utilisé les mêmes machines, mais les optimisations diffèrent. Surtout, ces benchmarks n’ont qu’une valeur indicative. Les biais techniques et cognitifs sont rapidement visibles : tous les éditeurs défendent leurs choix technologiques.

Structurellement, les projets open source sont proches, mais quelques éléments les distinguent. Le plus évident concerne la manière de gérer l’envoi des messages vers les topics via les brokers. L’autre, fortement défendu par les contributeurs de Pulsar, c’est l’architecture « multicouche » qui « découple complètement la couche de stockage de la couche de messaging », selon les termes de David Kjerrumgaard, Principal software engineer chez Splunk en provenance de Streamlio, une startup spécialiste de Pulsar rachetée par l’éditeur de solutions de supervision IT.

Cette architecture se compose de trois couches : un ou des brokers (composés d’une API REST pour gérer les connexions des producteurs et des consommateurs et un « dispatcher », un serveur TCP asynchrone pour le transfert de données), un entrepôt de métadonnées gestionnaire du consensus (Apache Zookeeper) et une couche de stockage persistant (des nœuds Apache BookKeeper, aussi appelés bookies).

Cela rendrait Pulsar plus efficient en matière d’élasticité, donc plus adapté au cloud, puisque chaque composant majeur peut être mis à l’échelle séparément. La couche de stockage persistant BookKeeper permettrait de mieux répliquer les données et d’utiliser la fonction de géoréplication intégrée.

À l’inverse, Kafka repose sur un cluster contenant les brokers Kafka et s’appuie pour l’instant sur ZooKeeper pour la gestion du consensus, c’est-à-dire la répartition des partitions entre les nœuds. À cela s’ajoute cinq API pour l’administration, l’envoi des messages par les producteurs, l’accès aux topics par les consommateurs, la transformation de flux de données des topics d’entrée en topics de sortie, et l’acheminement de données de sources par le biais de connecteurs. Pour autant, le système de messagerie a largement fait ses preuves et supporte davantage de langages de programmation, même s’il peut être parfois difficile à gérer.

Mais Confluent a lancé à la fin de l’année 2019 un vaste projet de refonte de la technologie. Il intime le remplacement de ZooKeeper par le Controller Quorum, pour régir les métadonnées des partitions et des brokers. Ce quorum s’appuie sur le protocole Raft et doit simplifier la configuration de Kafka.