Monter une filière No-Code - retours d'expérience dans la data avec Data Fusion - Part III/III
Cet article est le troisième et dernier d’une série de 3 qui traitent d’un retour d'expérience autour de l’organisation d’une filière No-Code dans la data et avec l’outil Data Fusion de Google.
Article 3 - Évaluations de Data Fusion et conclusions projets
Evaluation de la maturité de la solution No-Code Data Fusion
Rappel et généralités
Rappel sur l’évaluation d’une plateforme No-Code dans notre précédent article (["Les Dix commandements d'une plateforme No-Code mature"](https://blog.octo.com/les-dix-commandements-dune-plateforme-no-code-mature/ .)). Un développeur No-Code est très sensible aux diverses fonctionnalités techniques des outils No-Code, comme par exemple générer une App mobile native. En revanche, la sensibilité aux fonctionnalités liées au développement, comme la gestion des versions par exemple, est beaucoup plus faible. Et pourtant, ces fonctionnalités de développement peuvent devenir indispensables lorsque le projet No-Code va au-delà du démonstrateur.
Rappel des niveaux d'évaluation :
Evaluation de la plateforme Data Fusion
Pour connaître le descriptif des niveaux d’évaluation par critère se référer à l’article (["Les Dix commandements d'une plateforme No-Code mature"](https://blog.octo.com/les-dix-commandements-dune-plateforme-no-code-mature/ .)).
Autres éléments d’évaluation pour la plateforme Data Fusion
Autonomie des ‘citizen developers’
Pour être autonome, un utilisateur doit
Comprendre l’écosystème GCP dans lequel se place Data Fusion,
Avoir des notions de traitement de données (filtrage, nettoyage, transformation),
Savoir comment s’y prendre pour résoudre un problème sur un flux - méthodologie de résolution d’incident - (ex. Savoir où trouver les logs, les comprendre un minimum, savoir retranscrire à la cellule support…)
Gestion des erreurs et logs
La maturité est faible car les logs produits restent très techniques, assez bas niveau et/ou peu explicites ; sans la cellule support point de salut. Mais même avec ces informations, la cellule support a été amenée à tester en mode debug certains flux.
Le mode debug (fonctionnalité “Preview”) peut être utilisable sans pré-requis technique, mais se limite aux flux en cours de création en phase de build. Il est impossible d’utiliser le mode Preview pour un flux déjà déployé en production; il faut systématiquement le cloner dans un environnement de développement pour le tester puis le corriger avant de le redéployer.
Connecteurs
L’une des grandes forces de Data Fusion est son catalogue de connecteurs techniques et progiciels. Ainsi, la majorité des sources potentielles de données peuvent être accédées grâce aux connecteurs présents dans la plateforme. De plus, il est possible de développer de nouveaux connecteurs et de les intégrer facilement dans une instance Data Fusion.
Point de vigilance toutefois : les risques de trouver des dysfonctionnements (manques ou bugs) dans les plugins officiels restent élevés. Sans une cellule support en capacité à étendre ou créer des plugins customs pour combler ces manques point de salut. Exemples : les plugins API (http) présentaient de nombreux manques en terme d’authentification et des bugs bloquants récurrents, les plugins liés à l’univers GCP, bien que plus épargnés, présentaient eux aussi des bugs impactants (mauvaise gestion de champs optionnels, manque de certaines options de configuration). Ces manques sont principalement imputables à la jeunesse de la plateforme.
Le risque de trouver des dysfonctionnements dans les plugins officiels reste élevé
Eco-système Open Source
Les plugins disponibles dans Data Fusion sont tous Open Source et disponibles sur Github.
Comme dit dans le point précédent, une partie des plugins existants sont peu matures (bugs et manque de fonctionnalités). Il est possible de demander la correction d’un bug ou l’évolution d’une fonctionnalité en passant par le support. Cependant, ces changements peuvent prendre plusieurs mois avant d’être disponibles dans Data Fusion (une release de Data Fusion tous les 3 à 4 mois environ), voire être jugé trop spécifique pour être intégré dans l’outil.
Accéder au code des plugins permet de créer une version custom du plugin, et d’y intégrer de nouvelles fonctionnalités ou des corrections de busg soi-même et ainsi d’éviter que les utilisateurs finaux restent bloqués. Comme nous l’avions déjà fait remarqué dans nos précédents articles, le No-Code se transforme vite en Low-Code ;-). Toutefois, c’est bien la cellule support qui se charge de ces développements afin que les utilisateurs finaux restent sur un usage No-Code de la plateforme.
Un développeur Java pourra ainsi développer un nouveau plugin à partir de 0, ou récupérer le code des plugins officiels et y faire des modifications. Une fois le nouveau plugin développé, il suffit de builder le plugin et de l'importer dans Data Fusion pour que les utilisateurs de la plateforme puissent en bénéficier.
Si les modifications sur un plugin officiel sont suffisamment génériques, il est possible de proposer les évolutions/corrections dans une Pull Request pour permettre de faire évoluer les plugins officiels.
Cependant, les équipes de Google sont malheureusement peu réactives pour intégrer les évolutions proposées par la communauté aux plugins officiels (certaines Pull Requests restent ouvertes pendant plus d’un an sans réelle réponse).
Google est peu réactif pour intégrer les évolutions de la communauté aux plugins officiels
Eco-responsabilité
Comme il est possible de monitorer les flux et les applications, il est possible d’éteindre les inactifs ou les abandonnés utilisant des ressources inutilement (cf. instanciations zombies). On peut aussi surveiller efficacement une mauvaise manipulation pouvant entraîner des surcoûts donc des sur-utilisations de ressources IT. Ainsi, en optimisant les coûts on participe à une utilisation optimale des ressources IT liées à la plateforme No-Code.
Google dans l’univers GCP notifie les utilisateurs sur les ressources non utilisées et permet de faire des économies en évitant le gaspillage de ressources. Il y a par ailleurs, la possibilité de limiter l’usage des ressources, de les caper et éviter les débordements grâce à une gestion par quotas.
Tout ceci, ne préjuge ni d’une quantité injustifiée, ni de la pertinence des cas d’usages testés, bien entendu ;-). Une ressource non utilisée, c’est toujours mieux qu’une ressource mal utilisée.
Conclusion pour la plateforme Data Fusion
Release notes Data Fusion : https://cloud.google.com/data-fusion/docs/release-notes
Conclusion
Une cellule support indispensable pour accompagner les “citizen developers”
Une filière No-Code implique la mise en place d’une cellule support qui accompagne, forme et aide les “citizens developers” à être de plus en plus autonomes. Cette approche permet de mutualiser les efforts et les coûts en ressources humaines IT pour développer les flux.
Les ressources rares et chères de Data Engineering, finalement en nombre réduit, sont du côté de la cellule. Elles concentrent leurs efforts sur des présentations/formations et sur des développements de composants réutilisables par l’ensemble des BUs en limitant ainsi les développements “custom”. Leurs efforts compensent aussi la jeunesse voire la stratégie de la plateforme - Google privilégiant les évolutions autour de son propre écosystème. La cellule fait l'interface avec l’éditeur voire corrige directement les bugs de la plateforme (cf. avantage d’être sur une plateforme OS).
La cellule support aide les “citizens developers” à être de plus en plus autonomes
N’est pas “citizen developer” qui veut
Enfin, et cela est vrai autour de n’importe quelle filière No-Code, n’est pas “citizen developer” qui veut. Dans le cas de Data Fusion nous avons vu que les pré-requis impliquent à minima de comprendre l’écosystème GCP, d’avoir des notions de traitement de données et enfin de savoir comment s’y prendre (méthodologie) pour résoudre ou expliquer un problème sur un flux. Dit autrement, il faut à minima savoir globalement appréhender la technicité des flux au travers de l’outil Data Fusion. Les BUs qui ont d’ailleurs eu le plus de mal à gagner leur autonomie et ce malgré tous les apports de la cellule support sont celles qui n’avaient pas en leur sein de profils avec ce minimum vital de compétences techniques.
N’est pas ‘citizen developer’ qui veut
Data Fusion peut être utilisé pour implémenter des flux exploratoires non critiques
Alors que la plateforme Data Fusion et son environnement seuls ne sont pas encore optimaux, grâce à la cellule, les BUs ont pu faire ce qu’elles souhaitaient de manière de plus en plus autonome et pour des coûts maîtrisés. Data Fusion peut être utilisé pour implémenter des flux exploratoires non critiques. Un bilan positif donc, puisque grâce à une cellule support de 3 personnes qui est venue soutenir et accompagner dans la durée les fameux ‘citizen developers’, en un an, une vingtaine de BUs ont implémenté jusqu’à une centaine de flux chacune grâce à 1 à 2 personnes formées en leur sein sur l’outil Data Fusion. L’autonomie des BUs a été atteinte en 2 mois maximum.
Positivement sur la plateforme Data Fusion on constate :
Une interface graphique lisible et facile à prendre en main,
La force de GCP sur laquelle elle s’appuie,
Des efforts significatifs de la part de Google pour que les coûts autour de Data Fusion restent bas car son objectif reste une conquête d’utilisateurs sur son cloud,
- Si vous reposez déjà sur des infrastructures GCP alors le coût de la solution Data Fusion est particulièrement modéré
La possibilité d’un monitoring pour détecter rapidement et efficacement une mauvaise manipulation entraînant des surcoûts + des possibilités d’utiliser les quotas via GCP. Limite par la même occasion le gaspillage des ressources IT mises en jeu. Rappel : ceci sans préjuger d’une quantité injustifiée ou de la pertinence des cas d’usages testés, une ressource non utilisée, sera toujours plus éco-responsable qu’une ressource mal utilisée.
Dans un contexte sensible au RGPD, la possibilité d’héberger les données en entrée ou en sortie en dehors de GCP (attention toutefois à la difficulté à gérer des environnements moins intégrés donc moins performants)
Au delà des défauts déjà mentionnés, les points d’amélioration et attentes sont sur
Le versioning des flux qui n’est (pour l’instant) pas géré
Les flux déployés ne sont pas éditables. Pour les modifier il faut passer par une opération de clonage avant de les modifier puis de les redéployer - l’environnement multi utilisateurs est donc perfectible à ce stade ;-)
Data Fusion peut être utilisé pour implémenter des flux exploratoires non critiques