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 workflow n’importe où.

Azure Logic Apps suscite un vif intérêt avec plus de 40 000 clients qui 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.

Logic Apps (les nouveautés)

Microsoft a présenté l’année dernière le concept de la nouvelle version Logic App Standard nommé Logic App Preview en s’appuyant sur le modèle d’extensibilité Azure Functions. Depuis lors, la ferme 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 reçu des commentaires de la communauté, menant à la version GA.

En gros l’idée repose sur l’architecture des microservices combinés considérés comme des workflows. Appeler différentes API et tout rassembler. L’intégration est le paquebot de cette transformation et la colonne vertébrale de ces workflows.

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

  • Nouvelle interface Utilisateur
  • Support d’Application Insights
  • Le Scaling
  • Support de Visual Studio Code WYSIWYG
  • Logic Apps s’exécute et testée en local (avec des points d’arrêt “Breakpoints”).
  • Logic Apps peut s’exécuter dans un App Service Plan
  • Logic Apps peut s’exécuter On-Premise avec Azure Arc & une cluster Kubernetes. Tout ça peut être combiné Azure Monitoring via Application Insights.
  • Logic Apps peut être déployée sans ARM template. On peut utiliser des actions GIT-hub écrites in YAML.
  • Publier/Souscrire (Pub/Sub) aux évènements: Via Event Grid
  • Control d’accès, analyse, et gestion des APIs: Via Api Management

Petit à petit, la plateforme Logic App gagne en maturité. Cela montre qu’elle est là pour rester et que nous pouvons nous attendre à encore plus d’améliorations à l’avenir.

Logic Apps : Les Nouveaux Scénarios

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 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écurisez 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.

Et la nouveauté alors ? 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)

Le modèle Statefull est un peu plus lent par rapport aux autres technologies mais très populaire en raison de sa facilité d’adoption. Pour l’audit, le rejeu (resubmit) et le troubleshooting, vous sauriez 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 devez faire des efforts supplémentaires pour les sécuriser.

Maintenant, vous avez une option sans état (Stateless) où vous avez beaucoup plus de bande passante. Ce sera moins cher par rapport aux workflows avec état (Statefull) car vous ne faites pas toutes les opérations qui impliquent l’état et favoriserez la confidentialité des données. Vous avez toujours le choix de combiner le meilleur des deux lorsque vous en avez besoin.

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, vous l’auriez sur Statefull. Mais ce n’est pas vrai dans l’autre sens. Par exemple, vous n’avez pas la possibilité d’avoir des déclencheurs (Trigger) de connexion managées. Tous les déclencheurs qui sont 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. Etant un service Azure, lié à un Resource Group, il fallait traiter chaque instance individuellement, les paramétrer et les déployer avec ses propres composants.

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

Quels sont les pièges dans ce cas ? L’essentiel est votre choix de stockage. Par exemple, si j’utilise Logic Apps sur Docker, je ne suis 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 n’avions que la possibilité de faire de l’intégration sortante. Vous pouvez le connecter à une machine virtuelle (VM) sur un réseau virtuel Vnet, mais utilisez toujours la passerelle de données sur site (On-Premises Data Gateway).

Quoi de neuf maintenant ? Intégration du réseau virtuel et 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. Assurez-vous de bien comprendre vos choix. Ne jetez pas le modèle plan de consommation, elle 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 créant un nouveau. (Similaire à la création d’une fonction Azure).

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

Allons explorer et comprendre le point par point comme indiqué dans la figure ci-dessus :

  • Le 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.

  • Le 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 :

  • file d’attente de messages unique
  • partition unique

Veuillez noter que 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.

  • Le N°3 – Compte de stockage

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

File d’attente (Queue) : Dans le point 2 précédent, 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 des files d’attente peuvent être augmentées 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, sinon cela ralentira 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.

  • Le 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, il est livré avec 3 plans ASP de niveau de production (WS1, WS2 & WS3)

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 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 qui est 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) ou 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-le 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, cela ne peut aider 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.

Prochainement, une fois la deuxième partie de ce blog est prête, je vais aller un peu plus loin en expérimentant les nouveautés Logic App Standard dans un cas réel et vous montrant ainsi comment appréhender cet rapidement mais efficacement !