Au début, les activités à haut rendement étaient informatisées. Puis, petit à petit, l’informatique s’est infiltrée dans toutes les activités des entreprises. Direction, comptabilité, marketing, production, … chaque service a eu droit à ses applications pour automatiser son travail.
Si pour une petite entreprise, cela ne représente que quelques logiciels, pour une entreprise de taille moyenne ou grande, ce sont désormais des centaines d’applications qui sont utilisées quotidiennement.
Rome ne s’est pas faite en un jour. Et dans le domaine de l’informatique, les révolutions ont été nombreuses. Mais ces dernières ne coupaient pas toujours la tête aux anciennes applications. Ainsi, il n’est pas rare de trouver un serveur Cobol bloqué dans un placard.
Il arrive que le système d’information (SI) d’une grande entreprise soit un enchevêtrement d’applications qui partagent parfois les mêmes sources de données (bases de données, fichiers, services externes, …) et échanges des services entre elles à travers des technologies (le savon et le repos, …) aussi variées qu’exotiques.
Au final, le SI d’une grande entreprise ressemble à un plat de spaghetti à la carbonara : des applications et des services reliés par des liens. Les schémas d’architectures des SI modernes effraieraient même le plus expérimenté des plombiers et donneraient des migraines au moindre architecte devant l’organisation improbable des réseaux de fluides.
Ce ne sont pas les solutions qui manquent pour répondre à ce besoin, mais une s’est imposée : ‘Kafka’. L’idée est simple, séparer les applications qui consomment des données de celles qui en produisent. Pour cela, une couche intermédiaire (middleware) est définie. Elle agit en intermédiaire entre l’application utilisatrice et l’application source.
Une application a besoin d’accéder à une nouvelle source de données, elle crée un connecteur vers Kafka. Ensuite ce dernier se charge de trouver le bon connecteur vers la source de données afin de permettre l’échange. Si le connecteur vers la source de données n’existe pas, il est créé. Il apparaît alors 3 couches : les connecteurs (connect) des consommateurs, le moteur de liaison (cluster), les connecteurs des producteurs.
Bien sûr Kafka se doit d’être universel et rapide. Clients et producteurs sont répartis sur les réseaux. Kafka répartit donc leurs échanges (topics) à travers des intermédiaires (brokers). Pour aller plus vite et assurer la redondance des données, les échanges peuvent être répartis dans des partitions.
Ainsi, applications clientes et sources d’informations sont clairement identifiées et ne sont plus mélangées dans le schéma du SI. Cette organisation en couche rappelle les lasagnes. Comme quoi, une bonne organisation des applications, c’est surtout une affaire de cuisine. Désormais Kafka décrit une organisation de l’information cohérente, simple à comprendre et efficace.
Pourtant quelque chose me gêne dans ces lasagnes. À quel moment le consommateur décide-t-il de l’information qu’il souhaite accéder ?
Lorsqu’on consulte des articles ou que l’on lit des fils d’actualité sur des réseaux sociaux, on choisit un ‘Topic’ particulier. Mais si je souhaite trouver une référence d’un produit particulier ou consulter mon dossier, il me faut bien envoyer un message au producteur pour qu’il traite ma commande.
Rien ne m’interdit dans ce modèle kafkaïen de me placer des deux côtés même si je ne suis producteur que d’une simple commande et mon fournisseur est consommateur pour recevoir celle-ci. Ne reste qu’à l’informaticien de créer ou de paramétrer les connecteurs qui permettront cela dans le cluster Kafka. Simple et efficace.