Aller au contenu principal
DIVERSITY. We make IT happen

Vos transactions, en flux continu.

Kafka, NATS, RabbitMQ, MQTT ou ActiveMQ, exploités pour vous au plus près des instances et des bases de données que vous avez déjà chez nous. Nos ingénieurs data relient le broker aux systèmes qui ont besoin de vos événements, y compris ceux qui tournent chez AWS, Azure ou GCP.

Gratuit, 60 minutes

Diagnostic écrit sous une semaine

Un ingénieur au bout du fil

Déjà chez nous

Adoptez le streaming d'événements sans multiplier les fournisseurs.

Vous êtes déjà sur notre cloud, vous avez une base de données infogérée chez nous ou vous développez sur notre plateforme de données ? Le broker s'installe dans le datacenter de votre choix, au plus près de ce que vous hébergez chez nous, et nos ingénieurs data le raccordent à vos systèmes. Ce qui tourne dans un cloud public se connecte au broker en peering direct.

Un exemple concret : vos commandes, au fil de l'eau

  1. 01

    Votre base de données

    Nos ingénieurs branchent Debezium sur le journal de transactions de votre PostgreSQL infogéré. Le code de votre application ne change pas.
  2. 02

    Un topic

    Chaque commande créée ou modifiée devient un message dans un topic Kafka, sur le même site que la base de données.
  3. 03

    Votre WMS

    Nos ingénieurs développent un consommateur qui tourne à côté de vos applications et alimente votre système de gestion d'entrepôt (WMS) dès qu'une commande arrive.
  4. 04

    Exploité par nos équipes

    Correctifs, supervision, sauvegardes et, sur un cluster, bascule au sein du site. Votre prochain topic s'ajoute au même broker.

Déjà client ? L'appel de diagnostic part de ce que vous hébergez chez nous. Demander un appel

Architecture : un broker infogéré au sein du réseau DIVERSITY. Il est relié à vos applications, qui tournent sur des instances cloud du même site, à quelques millisecondes du broker. Il est aussi relié à Debezium et à Kafka Connect, qui lisent votre base de données, ainsi qu'à notre plateforme de données. Vos bureaux, vos datacenters, vos usines et vos sites distants se raccordent au broker via Private Link, et les systèmes hébergés chez AWS, Azure, GCP, Oracle et Cloudflare y accèdent en peering direct sur des points d'échange européens. En option, une réplique sur un second site dans l'UE est reliée au broker par notre propre réseau de niveau 2.

Clouds publics

AWS, Azure, GCP, Oracle et Cloudflare

Bureaux et datacenters

Usines et sites distants

Réseau DIVERSITY

Broker infogéré

Kafka, NATS, RabbitMQ, MQTT ou ActiveMQ. Instance unique ou cluster.

Second site dans l'UE

Réplique en option, conçue et mise en place avec vous.

Vos applications

Sur des instances cloud. Elles produisent et consomment des données.

Debezium / Kafka Connect

Nos ingénieurs data le mettent en place.

Plateforme de données

Nos ingénieurs peuvent alimenter son data lake en événements.

Votre base de données

PostgreSQL, MySQL ou MongoDB infogéré

Private Link

Notre routeur, notre fibre
ou un tunnel

Peering direct

Sur des points d'échange européens

Même site :
quelques ms

Notre propre réseau de niveau 2,
et non l'Internet public

L'offre

Le broker seul, ou avec nos ingénieurs.

Cinq brokers, en instance unique ou en cluster, entièrement infogérés dans les deux cas. Faites appel à nos ingénieurs data quand les événements doivent atteindre les systèmes que vous exploitez déjà.

Apache Kafka

En mode KRaft. Pas de ZooKeeper à exploiter en parallèle.

NATS

Core NATS pour du pub/sub sans persistance, ou JetStream quand les messages doivent survivre à un redémarrage.

RabbitMQ

Files d'attente et exchanges, pour les équipes qui raisonnent déjà en ces termes.

MQTT

Eclipse Mosquitto, pour la télémétrie des objets connectés et des capteurs.

ActiveMQ

JMS, pour les applications Java d'entreprise et tout ce qui s'appuie déjà dessus.

Une couche d'intégration, pas un broker

Debezium / Kafka Connect

La couche d'intégration qu'utilisent nos ingénieurs pour transformer chaque modification d'une base de données existante en message.

NATS

Le NATS que nous vous proposons, nous l'utilisons nous-mêmes.

Nous utilisons NATS dans notre propre environnement de production, et c'est pour cela que nous le proposons. Notre logo figure sur la page d'accueil de nats.io, parmi les entreprises qui l'utilisent.

Voir notre logo sur nats.io (s'ouvre dans un nouvel onglet)

Le broker seul

Choisissez le broker et la topologie, instance unique ou cluster. Nous l'exploitons, avec 99,9 % de disponibilité contractuelle.

  • Correctifs et mises à jour

    Nous appliquons les montées de version et les correctifs de sécurité.
  • Supervision et alertes

    Nous le supervisons et vous appelons quand une intervention de votre part est nécessaire.
  • Sauvegarde et restauration

    Une sauvegarde toutes les heures. Nous conservons les sauvegardes les plus récentes : 24 horaires, 7 quotidiennes, 4 hebdomadaires, 12 mensuelles et 3 annuelles.
  • Bascule au sein d'un site

    Sur un cluster, la bascule se fait d'un nœud à l'autre, dans le datacenter que vous avez choisi.

Avec nos ingénieurs

Le même broker infogéré, que nos ingénieurs raccordent à votre existant.

  • Change Data Capture (CDC)

    Debezium et Kafka Connect branchés sur vos bases de données sources : infogérées chez nous, ou exploitées par vos soins si elles sont reliées à notre réseau par une connexion privée en TLS, pour que chaque modification devienne un message.
  • Conception des topics

    Des topics et une rétention pensés pour ce que vous faites réellement transiter.
  • Consommateurs branchés sur vos systèmes

    Nous développons les consommateurs qui acheminent les événements vers votre WMS, vos applications ou le data lake de notre plateforme de données.
  • Un second site

    Une réplique sur un autre site dans l'UE, par notre propre réseau de niveau 2, conçue et mise en place avec vous. C'est la première étape pour faire face à la perte d'un site entier.
Le bon choix ?

Le streaming d'événements en vaut-il la peine ?

Si vous vous reconnaissez dans l'une de ces deux situations, probablement. Sinon, un batch de nuit fera peut-être l'affaire pour moins cher, et nous vous le dirons pendant l'appel.

Problème 01

Vos systèmes ont des heures de retard

La commande est partie, le prix a changé, le capteur s'est déclenché. Le système en aval ne l'apprend qu'au passage du prochain batch.

Problème 02

Chaque intégration a son propre script

Une équipe exporte un CSV pendant la nuit, une autre copie une table à heure fixe, une troisième garde un script auquel personne ne veut toucher. Aucun de ces flux ne parle aux autres, et chaque nouveau raccordement repart de zéro.

Il vous faut des rapports et des modèles mis à jour à heure fixe plutôt que des événements au fil de l'eau ? Cela relève de notre plateforme de données.

Vous ne savez pas par où commencer ?

Dites-nous quels systèmes doivent se parler. Un appel gratuit de 60 minutes, puis un diagnostic écrit sous une semaine.

Gratuit, 60 minutes

Diagnostic écrit sous une semaine

Un ingénieur au bout du fil

Secteurs

Les secteurs où le streaming d'événements convient le mieux.

Des secteurs qui s'y prêtent naturellement. Une liste de cas d'usage, et non de références clients.

Banque, finance et assurance

Un flux de transactions que vos modèles antifraude lisent au fil de l'eau, plutôt que dans le batch du lendemain. Des positions et une exposition qui évoluent au rythme des opérations, et non à la clôture quotidienne.

Distribution et e-commerce

Des mouvements de stock et des changements de prix qui atteignent tous les canaux au même moment, sans qu'aucun système attende la synchronisation de nuit.

Industrie et production

La télémétrie des capteurs et des automates remonte de l'atelier en MQTT, dans un flux auquel vos systèmes s'abonnent, au lieu d'un fichier déposé à chaque fin de poste.

Énergie et utilities

La télémétrie des compteurs et du réseau, relevée au pas de mesure et transmise dès réception aux systèmes qui assurent l'équilibre offre-demande et le règlement des écarts.

Le broker n'est pas le plus difficile. Le raccorder à votre existant, si.

Trois façons de mettre un broker en production, et ce que chacune laisse à votre charge.

Critère

L'exploiter vous-même

Service infogéré américain

DIVERSITY

Brokers disponibles

Ceux que vous installez

Cela dépend du service

Cinq, entièrement infogérés

Correctifs et mises à jour

Votre équipe

Le fournisseur

Nous

Intégration

Votre équipe la développe

Vous, avec les outils du fournisseur

Nos ingénieurs data

En cas de panne

Votre astreinte

En général une file de tickets

Les ingénieurs qui exploitent le broker

Localisation

Là où sont vos serveurs

La région que vous choisissez

Quatre sites dans l'UE, au choix

Bascule

Celle que vous mettez en place

En général entre zones

En cluster, au sein d'un site

Injonctions extra-européennes

Cela dépend de votre hébergeur

Cela dépend : la maison mère américaine peut y être soumise

Aucune entité au-dessus de nous

Témoignages

Ce qu'ils disent de notre travail

« Debezium a fait de notre base de commandes un flux sans que nous touchions à une seule ligne de code applicatif. L'équipe de l'entrepôt a arrêté de nous demander des exports. »

Responsable plateforme

Industriel, Allemagne

1 sur 3

  • Santander
  • BASF
  • Commerzbank
  • AXA
  • Stellantis
  • Finnair
  • Siemens Healthineers
  • Marimekko
  • E.ON
  • Meliá Hotels International
  • Nippon Sanso
  • Siemens Gamesa
  • Ilunion
  • Douglas
  • IFEMA
  • Kemira
  • ISS A/S
  • Iberia
  • Comunidad de Madrid
  • Allianz

Ce qu'on nous demande avant de signer

Les questions qui reviennent, avec des réponses franches.

Ce n'est que du Kafka, non ? Nous pourrions l'exploiter nous-mêmes.

C'est possible, et beaucoup le font. Les correctifs, les mises à jour, la supervision et les restaurations sont alors aussi à votre charge. Nous exploitons le broker pour vous, au plus près de ce que vous hébergez chez nous, et nos ingénieurs data peuvent le raccorder à vos systèmes. La couverture des heures non ouvrées passe par l'offre de support avancée, qui est payante.

Est-ce vraiment Kafka, ou quelque chose de compatible ?

Nous exploitons Apache Kafka lui-même, en mode KRaft, et non un substitut compatible avec son API. Il en va de même pour NATS, RabbitMQ et ActiveMQ, ainsi que pour Eclipse Mosquitto côté MQTT.

Peut-on avoir plusieurs brokers, par exemple Kafka pour une équipe et MQTT pour nos capteurs ?

Oui. Chacun est provisionné sur ses propres instances : un cluster Kafka pour les événements applicatifs et un broker MQTT pour la télémétrie des objets connectés cohabitent sans qu'aucun des deux sache que l'autre existe.

Nos systèmes sont répartis entre vous et AWS, Azure ou GCP. Cela fonctionne-t-il quand même ?

Oui. Nous faisons du peering direct avec AWS, Azure, GCP, Oracle et Cloudflare sur des points d'échange européens, de sorte qu'un producteur ou un consommateur hébergé chez l'un d'eux atteint le broker sans passer par Internet. Nos ingénieurs peuvent aussi brancher Debezium sur une base de données que vous exploitez là-bas ou dans vos propres locaux, à condition qu'elle soit reliée à notre réseau en peering direct ou via Private Link et que la connexion passe en TLS. Nous ne lisons aucune base de données exposée sur l'Internet public. Vous n'avez rien à déplacer au préalable. Depuis une région de cloud public, la latence est celle qu'impose la distance ; une latence de quelques millisecondes ne vaut que sur un même site.

Ce service ou notre plateforme de données : lequel des deux nous faut-il ?

Notre plateforme de données sert aux traitements analytiques planifiés : des pipelines, un data lake et les rapports qui s'appuient dessus. L'offre Event Streaming, elle, fait circuler les événements entre les systèmes que vous exploitez, à l'instant où ils se produisent. Les deux se combinent : nos ingénieurs peuvent alimenter en événements le data lake de notre plateforme de données. Si ce qu'il vous faut, c'est un rapport chaque matin, commencez par la plateforme de données. L'appel de diagnostic vous le confirmera.

Que recouvre concrètement « entièrement infogéré » ?

Les correctifs et les montées de version, la supervision et les alertes, la sauvegarde et la restauration et, sur un cluster, la bascule au sein du datacenter que vous avez choisi. Le tout avec 99,9 % de disponibilité contractuelle, et un avoir automatique si nous ne l'atteignons pas. Le support est inclus dans tous nos produits, avec un délai de réponse cible de 4 heures par demande. L'offre de support avancée est payante : elle raccourcit les délais cibles et étend la couverture au week-end et aux heures non ouvrées. Un broker répliqué sur plusieurs sites n'est pas inclus : nous le concevons et le mettons en place avec vous, par notre propre réseau de niveau 2.

À quelle latence faut-il s'attendre ?

Quelques millisecondes quand vos producteurs et vos consommateurs tournent dans le même datacenter que le broker. Depuis un bureau ou une usine via Private Link, la latence dépend de la distance. La réplication vers un autre site passe par notre propre réseau de niveau 2 plutôt que par l'Internet public, mais la distance reste bien réelle. Nous ne publions donc pas de chiffre : une valeur unique pourrait être juste pour une paire de sites et trompeuse pour les autres.

Le broker est-il sauvegardé ?

Oui, et ce n'est pas facturé à part. Les sauvegardes ont lieu toutes les heures, et nous conservons les plus récentes selon une rotation grand-père-père-fils : 24 sauvegardes horaires, 7 quotidiennes, 4 hebdomadaires, 12 mensuelles et 3 annuelles. Nous ne publions pas encore de délai de restauration.

Par où commencer ?

Par l'appel de diagnostic, qui est gratuit. Pendant 60 minutes, vous échangez avec un ingénieur plutôt qu'avec un commercial, puis vous recevez un diagnostic écrit sous une semaine : quel broker, à quoi le relier et ce à quoi nous ne toucherions pas. Déjà client ? Même appel, même formulaire : dites-nous ce que vous hébergez chez nous et nous partirons de là.

Faut-il tout passer d'un coup en streaming d'événements ?

Non. Commencez par un seul topic, en général pour le flux qui pose déjà problème, comme celui des commandes ou des transactions, puis ajoutez des brokers et des topics au fil de vos besoins.

Où se trouvent nos données tant qu'elles sont dans le broker ?

À Madrid, Munich, Helsinki ou Amsterdam, selon le site que vous choisissez au départ. C'est notre propre matériel, dans nos propres datacenters. Le broker tourne sur ce site, et sur un second uniquement si vous nous demandez d'y mettre en place une réplique. La réplication entre nos sites passe par notre propre réseau de niveau 2 et ne quitte jamais l'UE.

Qui peut vous contraindre à remettre nos données ?

DIVERSITY est une entreprise européenne sans maison mère, américaine ou autre : il n'y a au-dessus de nous aucune entité à qui signifier une injonction extra-européenne. La réponse tient à notre structure, et non à une règle interne.

Cela pourrait aussi vous intéresser

Notre plateforme de données, c'est le versant batch : des traitements analytiques planifiés, sur un data lake que nos ingénieurs peuvent alimenter en événements. Notre cloud, c'est là que tournent vos producteurs et vos consommateurs. Enfin, le conseil IT, c'est pour vos revues d'architecture, avec des ingénieurs pour en appliquer les recommandations.

On en parle ?

Un appel gratuit de 60 minutes, puis un diagnostic écrit sous une semaine.

Écrivez ou appelez : c'est un ingénieur qui vous répond, pas un robot.