Je vais tenter d'apporter quelques éléments de réflexion sur le sujet après deux ans d'expérience.
Tout d'abord, le contexte, cet usage est critique car il permet le financement de commerçants à travers l'Europe ce qui leur permet de disposer d'une réserve de trésorerie au quotidien. On n'est plus sur un usage analytique souvent mis en place sur le cloud mais sur une application critique de type batch.
Cet usage s'appuie sur une plate-forme data hébergée par Google ( gcp ). Elle a été construite les précédentes années à partir d'outils comme Terraform et Ansible.
Elle s'appuie sur un modèle en trois couches:
- une infrastructure commune à tous les usages;
- un socle technique délivrant des composants techniques génériques multi-usages ( ingestion de fichiers ou de messages, transformation et calcul de la donnée, export de données ... )
- une couche usage utilisant les composant techniques pour instancier des usages définis par le métier
Cette séparation entre la couche technique et la couche usage est intéressante car elle permet d'isoler le code métier du code technique et d'enrichir les composants techniques au-fur-et-à-mesure de l'ajout d'usages tout en assurant l'unicité de la couche technique.
De plus, on peut alors distinguer deux types de développeur, les développeurs du socle technique, des profils plus pointus des développeurs de la couche usage, des personnes technico-fonctionnelles pouvant développer des usages dans un canevas préétabli et nécessitant moins de connaissances techniques.
Pour illustrer mes propos, sur le projet où je travaillais, les développeurs du socle technique codent et testent unitairement des composants écrits en Java sur un poste de dev, puis déploient les composants dans des pods kubernetes.
Les développeurs usage codent des dags Airflow qui se résument à des séquences d'appels aux composants du socle technique, il ne reste plus qu'à gérer les paramètres en fonction du contexte métier. Les traitements métiers sont, quant à eux, écrits dans un langage SQL enrichi avec des tags. Les tags permettent d'avoir des traitements métiers multi-usages, par exemple gérer une problématique multi-pays.
Ce type d'architecture permet d'avoir certes un pool restreint de développeurs pointus, mais surtout permet le développement rapide d'usages en se consacrant uniquement aux règles métiers à traduire sans se préoccuper des problématiques techniques sous-jacentes.
On pourrait même envisager d'aller plus loin en proposant une interface de règles métier dans la mesure où les règles métier sont traduites dans un langage déclaratif paramétré. On aurait ainsi un usage qui est capable de se modifier en temps réel ( pas de compilation, pas de déploiement, ... ). Une forme de nocode directement accessible aux équipes métier 😉
