Discussion :

[sloshy]

Bonjour,
désolé si je le poste est pas au meilleur endroit, j'ai parcouru les différents forums et j'ai pas trouvé mieux.
Je me permets de venir dire bonjour pour essayer d'avoir un échange, voir partager des ressources sur un problème de gestion de donnée en entreprise.

contexte
Plusieurs centaine d'application, chacune avec sa stack, sa base de donnée, ses middleware, le tout entremêlé de tel sorte que si tu touche quelque chose à gauche, ça pète à droite.

vision
basé les nouveaux projet sur du micro service, désilloter tout ce qui peut l'être, lancer un programme d'obsolescence sur ce qui peut l'être et laisser mourir de sa belle mort tout ce qui est trop touchy.
il va de sois que le métier n'a pas un euro à mettre la dedans.

idée
Se connecter à toutes les sources d'information pour dans un premier temps copier toutes les informations vers un datalake et ensuite placer un connecteur pour avoir les nouvelles données au fil de l'eau.
Ainsi, on ne touche pas au métier, et je me retrouve avec un énorme lake désordonnée mais avec toutes les informations actuellement jugée utile du SI et pouvoir repartir sur quelque chose de propre pour les nouveaux projets (qui se fourniront à partir de la sans rajouter des liens étranges dans l'existant.

choix et question
Je vois assez bien un système kafka pour gérer cela. les kafka connecte me permettent de me connecter à énormément de source de donnée (base de donnée, fichier texte, sap, bob ...) mais étrangement, je me vois mal stocker des tables dans des topics.
j'ai l'impression que kafka doit être l'outil central, mais je n'arrive pas encore à concevoir ou stocker les données, j'ai besoin d'un peu d'aide/échange à ce sujet.

si ça parle à certains, have fun.

[Waldar]

Votre refonte est vouée à l'échec partant de ce postulat :

il va de sois que le métier n'a pas un euro à mettre la dedans.

Là vous parlez d'une refonte complète du SI, de centaines d'applications, le coût est déjà monstrueux en soit (rien que le fait que vous bossiez là-dessus et pas sur des nouvelles features ça a un coût).

Sinon ce que vous proposez, c'était la mode en 2015 mais globalement toutes les promesses autour de l'architecture datalake ont été loin d'être tenues.

Kafka est un outil de streaming de données (duquel vous pouvez lire ou écrire à l'aide de microservices), vous avez bien raison ce n'est pas fait pour faire du stockage.
Regardez plutôt les solutions de stockage objets émulant du S3.

Attention aux architectures microservice, ça marche très bien dans le transactionnel (un click sur le site déclenche n actions dans les différents front-end et back-ends), mais ça marche moins dans les domaines analytiques (si vous devez faire transiter 100 To de données pour faire une analyse, ça va être compliqué).


Les choix d'architectures actuels s'orientent plutôt sur du datamesh, on sépare les activités de l'entreprise en domaines et les domaines sont autonomes (tant sur les équipes que les choix de solutions techniques).
Les communications inter-domaines sont possibles à la mode API REST, ça permet de bien contrôler ce qui est exposé et utilisé en inter domaine (et a priori c'est à cet endroit que le bas blesse chez vous).
Cette organisation nécessite une certaine taille d'entreprise.

Je n'ai pas de recul pour vous dire si les promesses sont tenues, mais je vous invite à jeter un œil au sujet.