Logic Apps Standard : les nouveautés

Azure Logic Apps évolue ! Lors de la conférence annuelle Build, Microsoft a annoncé la disponibilité générale (GA) de Logic App Standard, la dernière version de son offre d’intégration Platform as a Service (iPaaS). Logic App Standard est une nouvelle offre à tenant unique (single-tenant) permettant aux clients d’exécuter des workflows n’importe où.

Azure Logic Apps suscite un vif intérêt : plus de 40 000 clients l’utilisent. Il fournit des capacités pour créer et exécuter des workflows automatisés et orchestrer des processus métier pour connecter des centaines de services dans le Cloud et en local.

Nous vous proposons aujourd’hui de découvrir toutes les nouveautés de Logic App Standard.

Nouvelles fonctionnalités de Logic Apps

Microsoft a présenté l’année dernière le concept de la nouvelle version Logic App Standard (Logic App Preview) en s’appuyant sur le modèle d’extensibilité Azure Functions. Depuis, la firme a travaillé de manière intensive avec des clients de l’industrie dans diverses branches en utilisant la nouvelle version de Logic App et a intégré les commentaires de la communauté qui ont mené à la version GA (General Availability).

En résumé, l’idée repose sur l’architecture des micro-services combinés considérés comme des workflows. Il s’agit d’appeler différentes APIs et de tout rassembler. L’intégration est le paquebot de cette transformation et la colonne vertébrale de ces workflows.

Source : integrate2021 – keynote kick-off

Les Logic Apps ont été améliorées pour prendre en charge cette vue. Les fonctionnalités de Logic App Standard incluent désormais :

• Une nouvelle interface Utilisateur ;
• Un support d’Application Insights ;
• Le Scaling ;
• Le support de Visual Studio Code WYSIWYG ;
• L’exécution et le test en local de Logic Apps (avec des points d’arrêt « breakpoints ») ;
• La possibilité d’exécuter Logic Apps dans un App Service Plan ;
• La possibilité d’exécuter Logic Apps on-premise avec Azure Arc & un cluster Kubernetes. Ces éléments peuvent être combinés Azure Monitoring via Application Insights ;
• La possibilité de déployer Logic Apps sans ARM template : on peut désormais utiliser des actions GIT-hub écrites in YAML ;
• La possibilité de publier/souscrire (Pub/Sub) aux évènements, via Event Grid ;
• Le contrôle d’accès, l’analyse et la gestion des API via API Management.

Petit à petit, la plateforme Logic App gagne en maturité : une preuve qu’elle a vocation à s’inscrire dans la durée et que nous pouvons nous attendre à de nouvelles d’améliorations.

Les nouveaux scénarios de Logic Apps

Qui dit nouvelle version, dit un nouveau runtime, un outil de conception amélioré, différents modèles d’exécution, etc. Cela permet désormais d’établir des scénarios qui étaient complexes ou impossibles dans le passé et affecteront certaines de vos décisions de conception précédentes et futures.

Authentification basée sur les identités

Auparavant, à moins que vous sécurisiez vos Logic Apps en les masquant par APIM, le seul type de sécurité entrante était les clés partagées (Shared keys). Du point de vue sortant, vous aviez la possibilité d’avoir une identité associée à des connecteurs managés, qui appartenaient à chacun d’entre eux. Il n’y avait aucun moyen d’identifier la Logic App en tant qu’identité système.

⚠️ Nouveauté : l’authentification entrante basée sur OAuth sera disponible pour les Logic Apps sur le modèle de consommation (consumption plan) et pas encore sur le modèle standard. La possibilité d’utiliser les identités managées sera également disponible pour certains connecteurs sortants.

La gestion d’état (Stateless vs Statefull)

Bien qu’un peu plus lent par rapport aux autres technologies, le modèle Statefull reste très populaire en raison de sa facilité d’adoption. En l’utilisant pour l’audit, le rejeu (resubmit) et le troubleshooting, vous saurez exactement tout ce qui s’est passé, même en montrant des données qui, en théorie, pourraient être privées. Dans certains cas, vous devrez toutefois faire des efforts supplémentaires pour les sécuriser.

Dorénavant, il existe une option sans état (Stateless) dans laquelle vous bénéficiez de beaucoup plus de bande passante. Le coût sera inférieur par rapport aux workflows avec état (Statefull) car vous ne réalisez pas toutes les opérations qui impliquent l’état, et vous serez en mesure de renfocer la confidentialité des données. Bien entendu, vous avez toujours le choix de combiner le meilleur des deux selon vos besoins.

💡 Ce qui faut tenir : le choix entre Stateless et Statefull est une décision de conception. Passer du scénario Stateless au Statefull est relativement facile car tout ce que vous avez sur Stateless est disponible sur Statefull. Mais l’inverse n’est pas vrai. Par exemple, vous n’avez pas la possibilité d’avoir des déclencheurs (Trigger) de connexion managés : en effet, tous les déclencheurs sur Stateless sont des déclencheurs intégrés/natifs. Une autre chose à garder à l’esprit est que les variables ne sont pas disponibles sur Stateless.

Exécuter les Logic Apps n’importe où

Vous en avez probablement déjà beaucoup entendu parler, mais dans le passé, les Logic Apps ne fonctionnaient pas partout. En tant que service Azure lié à un Resource Group, il fallait traiter chaque instance individuellement, les paramétrer et les déployer avec ses propres composants.

Vous pouvez désormais choisir où vous souhaitez déployer les Logic Apps : sur Azure Functions, sur Azure App Service, sur Kubernetes, sur Docker ou sur n’importe quel autre fournisseur de Cloud, en contrôlant le livrable, le déploiement, le calcul, la consommation et le regroupement, et en tirant parti d’un bloc de construction plus petit et réutilisable.

Attention aux pièges ! Votre choix de stockage est essentiel. Par exemple, en utilisant Logic Apps sur Docker, vous ne serez pas totalement déconnecté d’Azure. Le stockage SQL est une option viable qui est actuellement en préversion privée.

Intégration dans le réseau privé

Dans le passé, nous avions uniquement la possibilité de faire de l’intégration sortante. Vous pouviez relier la Logic App à une machine virtuelle (VM) sur un réseau virtuel Vnet, mais utilisiez toujours la passerelle de données sur site (On-Premises Data Gateway).

Quoi de neuf maintenant ? Il existe dorénavant une intégration du réseau virtuel et une connexion hybride, une évolution de ce que On-Premises Data Gateway offrirait. En termes d’options entrantes, nous avons maintenant des points de terminaison privés (private endpoints).

Logic Apps a ouvert de nombreux nouveaux scénarios, rapprochant les workflows du développement d’applications, mais il s’agit toujours d’une nouvelle technologie et il existe des lacunes qui pourraient affecter votre conception.

Notre conseil : Assurez-vous de bien comprendre vos choix. Ne jetez pas le modèle plan de consommation, il fait aussi partie du puzzle.

Logic Apps : environnement d’exécution (Runtime)

Pour créer une ressource standard Logic App, il vous sera également demandé d’associer un compte de stockage Azure (Storage Account) en utilisant l’existant ou en en créant un nouveau (le procédé est le même que pour la création d’une fonction Azure).

Ci-dessous, voici la représentation schématique du runtime Logic Apps Standard. Nous verrons comment cela fonctionne en interne. Ce runtime utilise également un compte de stockage (queue, table et blob) uniquement pour les workflows Statefull.

Étudions chacun des 4 points clés de la figure ci-dessus :

• Point n°1 : les actions

Dans les nouvelles ressources du Logic Apps Standard, tout ce qui est défini dans le flux de travail (actions) s’exécute en tant que tâches.

Ce nouveau runtime convertit chaque flux de travail en un DAG (Directed Acyclic Graph) de travaux à l’aide du séquenceur de travaux, et la complexité du DAG de travaux varie selon les étapes définies dans le flux de travail. Veuillez noter que cela ne se produira que lorsqu’il y aura une demande/un événement pour le déclencheur du workflow.

• Point n°2 : le moteur d’orchestration (Job Dispatcher)

Pour les workflows Statefull, le moteur d’orchestration planifie les travaux dans les séquenceurs de travaux en les conservant en tant que files d’attente de stockage. Dans le moteur d’orchestration, plusieurs instances de Job dispatcher s’exécutent en même temps et ces instances de travail multiples peuvent en outre s’exécuter sur plusieurs nœuds de calcul (lors de l’utilisation de plusieurs instances dans la ressource Logic App Standard).

Les paramètres par défaut du moteur d’orchestration au niveau du compte de stockage sont :

• Une file d’attente de messages unique ;
• Une partition unique.

A noter : pour les workflows Stateless, l’orchestration gère l’exécution des tâches en mémoire au lieu d’utiliser une file d’attente de stockage (Queue). C’est la raison pour laquelle les workflows Stateless sont meilleurs en termes de performances, mais en ce qui concerne la stabilité de l’environnement d’exécution Logic Apps Standard, au cas où il serait redémarré pour une raison quelconque, vous perdrez l’état d’exécution des instances de workflows Stateless.

• Point n°3 : compte de stockage

Voyons ce qui se passe exactement dans le compte de stockage :

File d’attente (Queue) : dans le point n°2, nous avons vu le but et comment le moteur d’orchestration standard de Logic App l’utilise pour planifier les travaux DAG de workflow créés par le séquenceur de travaux. Pour augmenter l’efficacité des Job dispatcher, le nombre de files d’attente peut être augmenté dans le host.json. Tenez compte de la latence des exécutions des tâches du workflow, du pourcentage d’utilisation du processeur et du pourcentage d’utilisation de la mémoire avant d’augmenter la file d’attente : à défaut, vous risquez de ralentir le temps de traitement global.

Table : l’environnement d’exécution du Logic App Standard l’utilise pour stocker les définitions de workflow avec les fichiers host.json. En outre, il l’utilise pour stocker l’état du point de contrôle du travail après chaque exécution afin de prendre en charge la politique de nouvelle tentative au niveau de l’action, ce qui garantit également « au moins une exécution » pour chaque action. En plus de l’état du travail, il stocke également ses entrées et sorties dans la table.

Blob : si la taille de l’entrée et de la sortie du Job est importante, le runtime Logic App Standard utilise le stockage blob.

Vous trouverez ci-dessous une capture d’écran du compte de stockage au moment de la création de la ressource Logic Apps Standard. Vous pouvez clairement voir qu’Azure a créé une file d’attente par défaut et une table de définition de tâches pour prendre en charge l’exécution des tâches d’exécution Logic Apps Standard.

• Point n°°4 : l’environnement d’exécution Azure Fonction

Le moteur d’orchestration utilise l’environnement d’exécution Azure Fonction sous-jacent pour exécuter les tâches. Lors de la création de la ressource Logic App Standard, vous pouvez utiliser un workflow ou un conteneur Docker comme environnement d’hébergement d’exécution de l’application sous-jacente.

Plans d’hébergement ASP disponibles
Actuellement, le nouveau modèle Logic App Standard est livré avec 3 plans ASP de niveau de production (WS1, WS2 & WS3)

Source : Azure

Compte tenu de la bande passante que vous souhaitez maintenir en conséquence, vous pouvez sélectionner l’un d’entre eux.

Notez que le vCPU (virtual Central Processing Unit) indique le nombre de cœurs disponibles dans une instance. Il peut vous aider à identifier le nombre indicatif de tâches simultanées maximales autorisées par cœur en définissant Jobs.BackgroundJobs.NumWorkersPerProcessorCount dans le host.json (il est de 192 par défaut). Compte tenu de la latence des exécutions des tâches du workflow, du pourcentage d’utilisation du processeur et du pourcentage d’utilisation de la mémoire, cette valeur peut être augmentée ou diminuée.

Pour info: Si le pourcentage d’utilisation du processeur atteint 70 %, vous pouvez réduire ce nombre pour réduire les exécutions de tâches du workflow simultané (bande passante – Throughput). Si le pourcentage d’utilisation du processeur est faible, cela indique le CPU est sous-utilisé et vous pouvez toujours augmenter ce nombre pour maximiser les travaux du workflow simultané exécuté.

Paramètres de configuration d’exécution importants (bande passante) :

Jobs.BackgroundJobs.DispatchingWorkersPulseInterval : la valeur par défaut est 1 seconde. Utilisez ce paramètre pour contrôler l’intervalle d’interrogation du Job dispatcher pour sélectionner les messages (tâche suivante) dans la file d’attente de stockage.

Jobs.BackgroundJobs.NumWorkersPerProcessorCount : la valeur par défaut est 192. Ce paramètre peut être utilisé pour contrôler/restreindre l’exécution (bande passante) des travaux de workflow simultanés par cœur de CPU.

Jobs.BackgroundJobs.NumPartitionsInJobTriggersQueue : la valeur par défaut est 1. Ce paramètre n’est utile que dans le cas où plusieurs Job dispatcher s’exécutent sur un grand nombre d’instances sur plusieurs nœuds de calcul en arrière-plan.

Veuillez noter que les paramètres mentionnés ci-dessus peuvent être définis dans le fichier host.json.

Pour aller plus loin

Maintenant que vous avez découvert les toutes dernières fonctionnalités de Logic App, je vous invite à lire l’article suivant sur Azure API Management.