Editions ENI Livres | Vidéos | e-Formations
Conclusion
Développement Azure Data Factory
Le développement d’Azure Data Factory doit sans cesse être mesuré. Les métriques importantes sont : le temps de développement, la simplicité de maintenance, le volume de données à gérer, les temps d’exécution, et le coût Azure de la solution. Car l’un des intérêts majeurs du Cloud est de pouvoir obtenir simplement une quantité importante d’informations sur les temps de traitement moyens, les coûts moyens, le temps passé par les équipes avec l’utilisation d’Azure DevOps, le nombre de bugs, etc.
Et donc de savoir mesurer précisément les actions qui fonctionnent dans l’écosystème d’une entreprise donnée. Cela est rendu nécessaire par la multiplicité des solutions possibles à un problème donné. Un problème ayant plusieurs solutions, pour prendre une décision en conscience, il est donc nécessaire d’évaluer les solutions implémentées et d’en tirer des conclusions qui avec le temps préciseront les solutions à privilégier.
État de la solution
Azure Data Factory n’est pas le successeur de SSIS que certains voudraient voir. Porté par les possibilités offertes par le Cloud, les paradigmes sont différents. Séparation du traitement (Compute) et du stockage, symbiose avec des services extérieurs tels qu’Azure Function, Logic Apps, Azure Key Vault, Azure DevOps sont au cœur de l’architecture d’Azure Data Factory. Si la version 1 de l’outil manquait cruellement de flexibilité et d’outillage, la version 2 combinée avec l’arrivée des Data Flow surpasse de loin son cousin lointain.
L’absence d’intégration au sein de Visual Studio peut de prime abord heurter, mais cela est la garantie de mises à jour régulières au sein du portail Azure qui facilite le déploiement régulier de nouvelles fonctionnalités. De plus, le développement hors ligne n’aurait d’intérêt que s’il était possible de l’exécuter localement, sur un émulateur par exemple et cela ne semble pas prévu.
Avec Mapping Data Flow, un niveau de flexibilité jamais égalé est à portée de main, schéma flexible avec la possibilité de gérer les colonnes dynamiquement, supporter des volumes de données gigantesques et cela, surtout, sans lignes de code. Certes...
Perspective d’avenir
Un des éléments fondamentaux d’Azure Data Factory est le support de l’authentification MSI (Managed Identities). Véritable compte de service dédié et sécurisé pour les ressources Azure, ce mode d’authentification doit se généraliser. Cela permettra une intégration facile entre les briques en ne rognant pas sur la sécurité. Aujourd’hui, trop peu de services supportent ce type d’authentification et surtout l’absence de support pour Azure Data Bricks qui exclut de facto leur utilisation au sein de Data Flow. La sécurité passe aussi par une gestion facilitée des secrets, l’intégration d’Azure Key Vault n’est pas chose aisée en dehors des quelques services liés qui le supportent.
Je rêve personnellement d’une activité Azure Key Vault qui me permette de récupérer simplement des secrets sur une étendue donnée. Avec cela, c’en est fini des chaînes de connexion en clair, ou la gestion artisanale des secrets à l’aide d’Azure Function.
Il semble que l’aire Azure Data Factory ne fasse que commencer, le développement de Microsoft est encore très actif sur le sujet, en particulier en ce qui concerne les Data Flow.
Tous les exemples illustrés dans cet ouvrage sont disponibles sur le dépôt...
