Bien souvent une dynamique de transformation digitale de votre entreprise va vous amener à sortir de votre « confortable » ERP (qui fait tout) pour intégrer de nouveaux outils.
Un CMS va venir gérer du contenu à destination du web, un PIM va enrichir votre contenu produit…
Chaque produit aura son propre domaine d’expertise et ceci va vous permettre de rapidement être efficace sur les sujets.
Sur le papier c’est super !
Seulement voila ! Derrière cette promesse il y a une contrainte.
C’est une contrainte qui, si elle n’est pas prise suffisamment à temps, peut significativement vous ralentir.
Je veux parler du maintien opérationnel des connexions entre les outils et de la cohérence des communications.
Fort heureusement, ce sujet n’est pas neuf, et il existe de nombreuses solutions pour répondre à ce problème (ETL, ELT, ESB, Middleware, API Gateway).
Cependant il est difficile de réellement comprendre laquelle utiliser et pourquoi 🤯.
C’est l’objectif de ce post, j’aimerais amener ma « pierre à l’édifice » afin de vous permettre de mieux comprendre l’outil qui serait adapté à votre organisation.
Les solutions de transformation de la donnée
Comme j’ai commencé à l’expliquer un peu au-dessus, il existe de nombreux outils qui permettent de transformer/manipuler de la donnée.
Ils n’ont pas réellement les mêmes objectifs, regardons en détail ces outils.
ETL (Extract Transfom Load)
Le terme ETL porte bien son nom :
Un ETL est donc (comme son nom l’indique) une somme d’opérations sur des données qui permet de :
- Collecter à partir d’un nombre illimité de sources (des fichiers, des bases de données…).
- Transformer, structurer ces données (nettoyer et standardiser les données).
- Centraliser ces données transformées dans un référentiel unique (le plus souvent un entrepôt de données).
Les ETL sont des outils couramment utilisés pour :
- Faire de la réplication de données.
- Faire de la migration de données d’une application vers une autre simplement en la transformant ou en venant appliquer un processus d’enrichissement de celle-ci.
- Stocker des données dans un datawarehouse.
- Synchroniser des données entre des systèmes.
Pourquoi utiliser un ETL
Les ETL sont conçus pour traiter des grandes quantités de données dans une seule extraction c’est donc un outil très adapté pour :
- Traiter un grand nombre de données avec peu de commandes.
- Faire des transformations complexes de données.
La limite d’un ETL est qu’il n’est pas fait pour être synchrone ou bi directionnel.
C’est donc un très bon outil pour alimenter de grosses quantités d’un système à un autre avec un fort besoin de transformation hors production et hors contraintes d’immédiateté.
Avec l’émergence du cloud, les ETL sont en cours de mutation, ils deviennent progressivement des ELT.
ELT (Extract Load Transform)
La petite sœur de l’ETL (L’ELT) elle aussi porte bien son nom :
La grosse différence entre l’ELT et l’ETL est que les données sont envoyées d’une plateforme à une autre sans les transformer (dans un premier temps) la transformation est un processus qui interviendra après (et lorsque ceci sera nécessaire).
Techniquement, dans un premier temps les données sont envoyées dans un entrepôt de données temporaire (Le plus souvent un DataLake) pour ensuite être transformées (lorsque ceci sera nécessaire).
L’utilisation des ELT prend son essor avec la montée en puissance du cloud car cette technologie lève un gros frein (dans les processus utilisés avec les ETL) qui était les capacités de stockage. Auparavant, pour stocker de la donnée il fallait acheter des environnements de stockages, les héberger… avec le cloud ceci devient beaucoup plus simple, moins cher…
Ce qui va changer pour les entreprises c’est la philosophie d’analyse et de stockage.
Avant il fallait être sur de ce que nous voulions stocker, comment nous voulions le stocker et déjà avoir pensé le besoin en termes d’analyse.
Avec l’ELT on pense d’abord à stocker de la donnée dans un énorme espace de stockage et on réfléchira (plus tard, lorsque le besoin se fera sentir) à l’utilisation de ces données.
Quittons maintenant le monde des bases de données pour nous intéresser au monde de l’orchestration de services.
ESB (Entreprise Service Bus)
Un ESB est une architecture intergicielle.
Grand frères de L’intégration d’applications d’entreprise (ou IAE en anglais entreprise application integration, EAI) le rôle d’un ESB est d’automatiser les échanges de données entre les éléments d’un SI en leur imposant un standard de communication.
Concrètement si vous avez dans vos outils informatiques des outils qui ne sont pas faits pour nativement communiquer, l‘ESB sera là pour créer cette communication grâce à des services.
Le principe de fonctionnement d’un ESB est le suivant :
L’ESB va créer des services qui seront publiés dans un registre afin d’être mis à disposition des différentes applications.
Une application pourra être distributrice ou consommatrice d’un service.
Le rôle de l’ESB ne s’arrêtera pas là, il va pouvoir apporter beaucoup d’autres avantages :
- L’ESB pourra être l’orchestrateur des services. Dés lorsque des outils auront besoin de plusieurs services c’est lui qui va venir les agréger pour normaliser le besoin de l’outil demandeur.
- Au besoin, L’ESB pourra prendre un rôle de transformateur de la donnée. L’objectif sera d’adapter la donnée à l’outil consommateur de celle-ci.
- L’ESB sera en capacité d’effectuer une traçabilité de la donnée. Ceci afin de s’assurer qu’une donnée aura bien été délivrée, au bon moment, au bon format…
- Enfin l’ESB sera en capacité de gérer une « file d’attente » des messages. Ceci permettra à des applications qui ne sont pas actives en même temps de communiquer (MOM).
Intéressons nous maintenant à un autre type d’orchestrateur de services, l’API GateWay (ou plateforme d’API en Français).
API GateWay
La plateforme d’API (ou API Gateway) a pour objectif de faciliter la communication entre des « clients extérieurs » et des services grâce aux API.
Comme son nom l’indique l’API Gateway va servir de passerelle pour permettre à des « clients externes » d’appeler des services internes (via des API).
Ne vous méprenez pas sur le terme « clients externes » nous parlons ici d’applications clientes. Une application cliente est une application qui sera la cliente d’un service. Le terme externe est galvaudé il signifie que l’application ne partage pas les mêmes bases et sera (le plus souvent) externe à l’entreprise (saas…).
On est d’accord je ne me suis pas trop « cassé la tête » pour faire ce schéma par rapport à celui de l’ESB 😅
En même temps ceci est normal nous parlons « grosso modo » de la même chose cependant, le diable se cache dans le détail 😈
Regardons dans le détail maintenant :
- Tout comme l’ESB, l’API Gateway va permettre d’orchestrer les services.
- Tout comme l’ESB, l’API Gateway va permettre de transformer les données, les formats, les protocoles…
- Tout comme l’ESB, l’API Gateway va permettre de monitorer les échanges.
Mais 2 choses vont changer par rapport à l’ESB c’est que :
- L’API Gateway va sécuriser les échanges (terminaison TLS, WAF….)
- L’API Gateway va vous permettre de monétiser vos API.
Au final, quelle solution de transformation de la donnée pour quel usage ?
Au final, nous avons deux grandes familles d’outils de transformation de la donnée :
- D’un côté, les outils qui permettent de transformer des données avec l’objectif de les stocker (ETL ou ELT) et ainsi permettre une utilisation « analytics » de celles-ci.
- De l’autre, les outils qui permettent de transformer des données à destination d’autres outils afin de faciliter la communication entre les outils (ESB ou APIGateway).
Vous vous demandez encore surement la différence fondamentale entre un ESB et une plateforme d’API.
Ceci est un vieux débat, je le résumerais de la manière suivante.
L’ESB permet à des applications hétérogènes de communiquer ensembles mais à partir du moment où l’on souhaite exposer des services vers l’extérieur il atteint ses limites. A partir de là nous aurons tendance à nous tourner vers des plateformes d’API afin d’assurer la sécurisation et la consommation des API.
A ce titre les plateformes d’API (en plus d’être indispensables pour des stratégies d’architectures en microservices ) sont un pas vers la plateformisation d’un business, là où l’ESB sera plutôt le garant des règles métiers.
