Confluent met sa plateforme cloud au diapason du Data Mesh
Confluent invite les entreprises à migrer vers Confluent Cloud, en assurant que la plateforme est adaptée à leurs charges de travail les plus complexes. Pour les convaincre, l’éditeur mise sur des fonctionnalités compatibles avec leurs stratégies Data Mesh. C’est également pour cette raison qu’il annonce un service managé consacré à Apache Flink.
Lors de sa conférence annuelle Current à San José, Confluent a mis en avant Confluent Cloud, sa plateforme SaaS.
Celle-ci repose sur son architecture cloud native, nommée Kora. L’année dernière, l’éditeur avait déjà mis en avant ce dispositif en assurant qu’il proposait des performances quatre fois supérieures à Apache Kafka open source. Ce sera bientôt jusqu’à 10 fois grâce à l’évolution des capacités de réplication, selon Julie Price, Senior Product Manager chez Confluent.
Mais c’est surtout la couche de tiering que l’éditeur a fait évoluer, afin de faire baisser les coûts de stockage de 20 % dès le 1ᵉʳ octobre. « Cela s’appliquera aux clients existants et aux nouveaux. Vous n’aurez rien à faire pour en profiter », assure-t-elle.
Cette évolution s’accompagne d’un forfait supplémentaire pour les clusters disponibles en mode autoscaling. Ce cluster Enterprise complète les offres « Basic » et « Standard ». Les clients disposent alors d’un point de terminaison dédié.
« Quand vous gérez Kafka par vous-même, vous devez prévoir les pics. Souvent, il faut surprovisionner l’infrastructure pour être sûr de ne pas subir de pannes, mais cela coûte cher et certaines charges de travail sont imprévisibles », constate Julie Price, lors d’un keynote de la conférence Current. C’est l’une des raisons qui a convaincu Michelin d’adopter Confluent Cloud. « Le cluster Enterprise est la réponse. Toutes les offres Confluent Cloud sont élastiques, mais Enterprise ne réclame pas de réserver des capacités : ce cluster peut monter à l’échelle de 0 à 1 Gb/s en quelques secondes sans préprovisionnement », assure-t-elle.
Cette montée en charge « instantanée » passe par une boucle de feedback qui observe les charges de travail et assigne des ressources quand le cluster approche un pic et les décommissionne quand elles reviennent à la normale. Cela permettrait de réduire « jusqu’à 40 % les coûts » par rapport à un cluster Kafka self-managed, avance Julie Price.
Pour l’instant, les clusters Enterprise sont disponibles sur AWS depuis huit régions cloud aux États-Unis, en Europe, en Asie-Pacifique et en Afrique du Sud (us east-1, east-2 et west-2, eu-west-1, eu-central-1, ap-southeast-2, southeast-2 et af-south-1). Le raccordement au réseau dédié est assuré via le service VPC AWS PrivateLink.
Confluent étaie (encore) Confluent Cloud
Les Clusters Enterprise n’ont pas de limites de stockage affichées, mais supportent jusqu’à 5 000 partitions pour les topics non compressés et 600 partitions pour les topics compressés. Ils disposent d’un SLA de 99,99 %. L’offre comprend une haute disponibilité à travers trois AZ. Un cluster de ce type peut prendre en charge jusqu’à 22 500 connexions et 37 500 requêtes par seconde, soit cinq E-CKU, l’unité de mesure choisie par Confluent pour définir la taille de ces clusters.
Pour rappel, l’éditeur avait lancé les clusters Kafka dédiés en juin dernier.
Par ailleurs, Cluster Linking, la fonction de réplication de Confluent Cloud, également utilisé pour la migration vers le cloud, se dote d’un mode bidirectionnel. Habituellement, un cluster link est un pont unidirectionnel d’un cluster source vers un cluster de destination. Ici, les données et métadonnées fluctuent dans les deux sens. Les clusters connectés sont ici à égalité. Cela améliorerait les politiques de récupération après désastre et permet (enfin) un véritable déploiement actif-actif.
En parallèle, l’éditeur fait évoluer son provider Terraform consacré à Confluent Cloud. Malgré la polémique causée par le changement de licence de l’outil IaC, l’éditeur ne tourne pas le dos à HashiCorp, au contraire. Il réalise une intégration avec HashiCorp Sentinel, le framework de gestion des politiques « as code » concurrent d’Open Policy Agent (OPA).
Il s’agit de mieux contrôler les accès aux ressources Confluent Cloud afin de renforcer la sécurité, de personnaliser des règles en fonction des obligations et des besoins des clients, mais aussi de centraliser ces politiques dans une vue unifiée.
Mais la mise à jour du provider Terraform apporte également la prise en charge de la collecte de métadonnées et d’étiquettes liées aux ressources Confluent vers un catalogue de données et la conversion d’une configuration de la plateforme en un modèle Terraform.
De plus, Confluent a introduit une méthode d’audit des événements pour les connecteurs personnalisés.
L’autre argument de Confluent pour les usagers de Kafka tient sur sa galerie de connecteurs. Outre 75 connecteurs « entièrement managés », l’éditeur a rendu possible le développement de connecteurs personnalisés depuis certaines régions AWS et a lancé en juillet le programme « Connect With Confluent ».
Des produits de données constitués dès la phase de streaming
« À travers ce programme, nous entamons des discussions avec des partenaires technologiques pour réaliser des intégrations directes de produit à produit », explique la Senior Product Manager.
Le tout converge vers sa suite Stream Governance, un pan de sa plateforme réservée à la gouvernance des flux Kafka et au maintien de produits de données, un concept directement lié à l’implémentation d’une stratégie Data Mesh.
Ces produits de données peuvent être conçus à l’aide de Schema Registry, un outil permettant d’établir des schémas de données s’appuyant sur les topics et les sujets Kafka. « Schema Registry fournit un langage commun de telle sorte que les producteurs, les consommateurs et les plateformes de données peuvent fonctionner en harmonie », vante Mike Agnich, vice-président Product Management chez Confluent.
Si ce tri des données a lieu dès la phase d’ingestion en quasi-temps réel, leur sécurisation doit évoluer, considère l’éditeur. Il intégrera une fonctionnalité de chiffrement côté client au niveau des champs de données. Ce chiffrement est (pour l’instant) fonction du KMS d’AWS et peut être appliqué via la console administrateur, à travers un système de règles (il est également possible de passer par un CLI).
Par ailleurs, Confluent introduira « prochainement » ce qu’il nomme Data Portal, un moyen de cataloguer des topics, d’en chercher, d’en découvrir et de consulter les tags et les métadonnées associés.
Cet outil est conçu pour les développeurs afin de retrouver les topics et les modèles de données qui propulseront leurs applications. Ils peuvent en demander l’accès à un administrateur Confluent Cloud pour les utiliser en mode lecture seule ou lecture et écriture. S’il est autorisé, l’usage sera représenté dans le data lineage intégré dans Data Portal.
Apache Flink débarque sur Confluent Cloud
L’évolution majeure pour Confluent n’est autre que le lancement en préversion publique d’un service managé pour Apache Flink. Pour rappel, Confluent participe activement au développement de Kafka Streams, une librairie Java pour construire des applications de streaming.
« Kafka Streams est très bon pour intégrer des primitifs de streaming de données dans n’importe quelle application event-driven », déclare Konstantin Knauf, Group Product Manager chez Confluent.
« Mais vous avez aussi cette famille d’outils et de frameworks qui vont plus loin : Materialize, Apache Spark, Apache Flink et ksqlDB », reconnaît-il.
Ceux-ci prennent en charge les aspects de gestion du cycle de vie, de rescaling, de gestion des états, ils sont tolérants aux erreurs et chacun d’entre eux apporte des fonctionnalités uniques, selon le responsable.
« De cette famille, nous observons qu’Apache Flink émerge comme un standard ».
Pour Confluent, il y a d’abord un aspect pratique : Kafka et le moteur de traitement de flux distribué se retrouvent souvent dans les mêmes environnements et architectures.
« De grands groupes dont ING, Uber, Visa, Salesforce ou encore Netflix, exploitent les deux technologies », poursuit Konstantin Knauf. Les topics Kafka sont généralement des sources de données pour Flink.
« [Flink] apporte un ensemble d’API […] qui permettent d’unifier les traitements batch et streaming et son runtime offre une faible latence et un large débit pour les applications stateful ».
Comme il l’a fait pour Apache Kafka, Confluent entend adapter l’architecture du moteur de traitement en streaming au cloud.
Cette préversion publique pour l’instant limitée à quatre régions cloud sur AWS s’appuie sur l’expertise d’Immerok, un spécialiste de Flink racheté par Confluent en janvier 2023. L’architecture mise en place fait cohabiter Kafka et Flink sur le même socle, Kora.
« Flink sert de couche de calcul en continu pour votre couche de stockage Kafka », résume James Rowland-Jones, directeur de la gestion produit chez Confluent. « Il permet aux développeurs d’interroger et d’inspecter les données en continu dans Kafka, ainsi que d’enrichir, de conserver et de transformer ces flux pour améliorer leur usage, leur portabilité et leur conformité ».
« Lorsqu’ils sont utilisés ensemble, Apache Flink et Apache Kafka peuvent favoriser la réutilisation des données et éviter les traitements redondants en aval. »
Matt AslettAnalyste, Vantana Research
Bien que Confluent vante les capacités de ksqlDB, son moteur SQL, celui-ci ne dépend pas d’une licence réellement open source et ne profite pas du même niveau d’adoption que Flink et Flink SQL. Même si Flink SQL est réputé pour sa plus grande complexité, il prend pleinement en charge le standard ANSI (et ne s’en inspire pas comme ksqlDB) et offre des capacités avancées. Or, à la différence de Kafka Streams, et comme Kafka, Flink a besoin de clusters spécifiques pour s’exécuter. D’où l’engagement de Confluent pour simplifier le déploiement de la technologie open source.
Flink serait un argument de plus pour déployer l’architecture technique nécessaire à la mise en place d’une stratégie Data Mesh.
« Lorsqu’ils sont utilisés ensemble, Apache Flink et Apache Kafka peuvent favoriser la réutilisation des données et éviter les traitements redondants en aval », affirme Matt Aslett, analyste chez Vantana Research, dans un communiqué de presse diffusé par Confluent.
Selon l’analyste, la fourniture de services entièrement managés « permet aux équipes de se concentrer sur la création d’applications de flux en temps réel et de pipelines qui différencient l’entreprise ».
Une petite touche d’IA générative
Flink sera également au cœur d’une initiative consacrée à l’IA. Au vu de l’effervescence autour de l’IA générative, Confluent a annoncé un ensemble de partenariats avec les éditeurs de bases de données vectorielles, dont Rockset, Pinecone, Zilliz, Rockset, Weaviate et MongoDB. Avec Google Cloud et Microsoft Azure, il s’agit d’exploiter les grands modèles de langage et les services d’IA que ces fournisseurs cloud mettent à disposition. L’objectif ? Développer des POC avec les clients de Confluent pour combiner IA générative et streaming de données.
De son côté, Confluent développe un assistant directement intégré à Confluent Cloud pour rapidement obtenir des informations sur la santé des clusters ou encore leurs coûts. Avec AI for Apache Flink, il s’agit d’intégrer les API d’OpenAI avec Flink SQL.
