Comment concevoir ma première application cloud native dans Azure ?

Contexte

Les applications monolithiques ont longtemps été considérées comme une référence dans l’industrie logicielle. Dans ce modèle, l’application repose sur une unique base de code. Les modules d’une application monolithique communiquent avec une seule et même base de données. Ce type d’architecture pose deux problèmes :

1. Un seul développeur peut difficilement comprendre l’application dans sa globalité du fait de sa complexité.
2. La modification d’une petite fonctionnalité va nécessiter un redéploiement complet de l’application.

Aussi, le modèle d’application Cloud Native introduit la séparation des applications en fonctionnalités indépendantes appelées microservices. Les applications gagnent en flexibilité et en modularité. Pour en savoir plus sur l’architecture Cloud Native, un article très complet est disponible dans la documentation Microsoft.

Construire une application Cloud Native distribuée nécessite des compétences en architecture pour intégrer la multiplicité des composants. Dapr (Distributed Application Runtime) est le Framework Open Source de Microsoft qui permet aux développeurs de construire facilement une application Cloud Native grâce à des blocs de construction réutilisables.

Nous allons voir dans cet article comment concevoir une application Cloud Native à partir d’un système d’analyse de Tweets. Nous allons expliquer comment des outils tels que Dapr, les services PaaS ou encore Bicep simplifient la vie des développeurs et accélèrent la construction d’une application.

Qu’est-ce qu’une application Cloud Native ?

Une architecture moderne et flexible

Une architecture cloud native est bâtie suivant trois piliers :

1. Le premier pilier repose sur l’utilisation de composants microservices. Les microservices peuvent être développés dans des langages de programmation différents, ce qui évite la dépendance envers une technologie. Ils sont flexibles, réutilisable et rendent les applications plus résilientes.
2. Un deuxième pilier repose sur l’utilisation de conteneurs. Une image de conteneur va contenir le code d’une application et ses librairies. Les conteneurs sont à la fois multi-plateformes, sécurisés et légers. Un service d’orchestration tel qu’Azure Kubernetes Services permet de provisionner des images de conteneurs Docker.
3. Le dernier pilier de l’architecture cloud native est l’utilisation de fonctions de type serverless. Un service tel qu’Azure Function permet d’exécuter son code source sans se soucier de l’infrastructure sous-jacente.

Un exemple concret : l’analyse de tweets

Pour illustrer ce qu’est « une application Cloud Native » nous utiliserons l’application Twitter Sentiment Processor mise à disposition sur le repository GitHub de la communauté Dapr.

Twitter Sentiment Processor sélectionne les tweets contenant un mot-clé spécifique (par exemple Microsoft ou Ignite) et leur donne une note avec une valeur comprise entre 0 et 1.
Une valeur de 0 est un tweet avec une émotion négative alors qu’une valeur de 1 est un tweet avec une émotion positive.

Cette application est composée de trois blocs applicatifs hébergés sur un cluster Kubernetes :

• - Le bloc Provider (1) se connecte à l’API de Twitter et recherche tous les tweets qui contiennent le mot-clé choisi. Ce composant stocke les tweets dans un Storage Account Il va également publier les tweets sur un topic d’Azure Service Bus.
• - Le bloc Processor (2) attribue une note de sentiment aux tweets grâce à l’utilisation d’Azure Cognitive Services.
• - Le bloc Viewer (3)est une Single Page Application développée dans les langages Go et Javascript. En utilisant les sockets, la partie Go du Viewer s’abonne à un topic proposé par Azure Service Bus. La partie Javascript de l’application va afficher la liste des tweets dans le navigateur de l’utilisateur.

• 

 

Dapr : un runtime pour développer plus rapidement des applications cloud native

Dapr est une partie importante de l’application de traitement de données Twitter. Ce runtime permet aux développeurs de construire rapidement des applications cloud natives résilientes et portables. Il est depuis sa version 1.0  (février 2021) utilisable dans un environnement de production. Dapr propose d’améliorer son application via des blocs de constructions. Ces blocs permettent notamment : de réaliser des liaisons avec des services externes (bindings), des invocations de services, de faire de la gestion d’états, de l’observabilité ou encore de stocker des secrets.

Chaque bloc propose un grand nombre d’implémentations. Par exemple, pour le bloc de construction gestion d’état, on a le choix entre plusieurs composants tels que Redis, MongoDB ou Apache Cassandra.

Dans notre application, nous utilisons trois composants différents :

• - Le composant Twitter (1) pour interagir facilement avec l’API de Twitter. Il se charge de l’authentification avec l’API et de faire la requête des tweets contenant un mot-clé spécifique.
• - Le composant Azure Storage Account (2) pour la sauvegarde des tweets. Sans même modifier le code source de l’application Provider, on pourra changer le stockage pour une base de données Redis.
• - Le composant Azure Service Bus (3) met en place un système pub/sub pour l’envoi des Tweets. On pourra très facilement utiliser un autre système tel que Redis en modifiant la définition du composant.

• 

Utiliser les services Azure PaaS pour améliorer notre application

Etudions désormais comment faire de notre solution une application de production en utilisant les services Azure PaaS, de gestion d’API et de messagerie. Tout d’abord, API Management va nous permettre d’exposer et de manager nos services sous forme d’API. Ensuite, Azure Function et Azure App Service vont respectivement déployer nos applications et exposer nos applications web de façon sécurisée. Logic Apps va nous permettre de décrire et d’organiser notre architecture. Enfin, Event Hub et Event Grid vont étendre les capacités de messagerie de Dapr.
 

API Management pour exposer ses services

La plateforme API Management (APIM) permet aux organisations de publier des API de façon sécurisée et fiable. API Management supporte le standard OpenAPI pour définir des contraintes de sécurité, limiter le nombre de requêtes ou encore implémenter un système de versioning. API Management permet également de définir des limites d’accès basé sur des rôles (RBAC). Dapr est à présent compatible avec API Management et supporte l’invocation trois blocs de construction différents : les invocations de service, les blocs de type pub/sub et les bindings de ressources.

L’intégration d’API Management Service avec Dapr nous permettra d’exposer plusieurs services :

• - La fonction Processor à l’adresse /process via une invocation de service.
• - La fonction Provider à l’adresse /provider grâce à invocation de service également.
• - Le binding Twitter à l’adresse /tweets via un binding de ressource.
• - La partie Stockage (via Storage table) à l’adresse /store grâce à un bloc de type pub/sub.

 

Bénéficier des avantages du serverless avec Azure Function

Azure Function est un service permettant d’exécuter du code sans se soucier de l’infrastructure et des ressources sous-jacentes. Azure Function supporte la programmation de type sans serveur (serverless) et événementielle (event driven) dans une multitude de langages de programmation.

Une extension Dapr est disponible pour utiliser les blocs de construction directement dans Azure Function. Dans notre exemple, on peut ainsi imaginer utiliser Azure Function pour héberger nos parties Provider et Processor.
 

Gérer ses ressources sous forme de Workflow via Logic Apps

Logic Apps est un service permettant d’automatiser et d’orchestrer différentes tâches grâce à la création de workflows. Un workflow est un ensemble de petites étapes permettant de créer un business process. Logic App Designer est un outil graphique permettant de créer un workflow très simplement.

Ces workflows sont désormais compatibles avec Dapr. Il est possible d’utiliser des invocations de services ainsi que des bindings en tant que déclencheur d’actions. Concrètement Dapr Workflow va résider dans un conteneur situé dans le même pod (groupe de conteneurs) que le sidecar Dapr. Les deux conteneurs vont communiquer via des requêtes gRPC.

Dans notre solution, cette partie workflow va remplacer le module Provider. Dapr exécutera automatiquement notre Workflow à la réception d’un tweet.

Le workflow se décompose en trois étapes :

• - Lecture des tweets via une liaison de type binding.
• - Invocation de la méthode sentiment-score pour noter les tweets.
• - Sauvegarde du tweet dans le compte de stockage.

 

Exploiter Azure App Service

Azure App Service est un service Azure en mode PaaS qui héberge des applications web de façon sécurisée. App Service intègre directement des fonctions de sécurité, de load-balancing, d’autoscaling et de management. Il est compatible avec une multitude de langages tels que Node.js, .NET, PHP ou encore Python. Nous allons pouvoir l’utiliser pour héberger le bloc Viewer de notre application.
 

Intégrer Azure Event Hub & Event Grid

Azure Event Hub est un service managé et temps réel d’ingestion de données (pipeline). Il est utilisé dans des cas où un large volume de données (big data) et d’événements à besoin d’être traité avec une latence faible et un haut niveau de disponibilité. C’est un bloc de construction de type pub/sub sous Dapr tout comme Azure Service Bus.

Azure Event Grid facilite la création d’applications basées sur les événements. Event Grid s’abonne à source de données (Event Source) tels qu’un Blob Storage puis envoie les événements vers un handler tels que Azure Function, Logic App ou Service Bus. Event Grid est disponible sous forme de binding avec Dapr.

Déployer l’application de façon rapide et automatisée

Dans cette partie, nous allons voir deux outils :

• - Bicep qui permet d’automatiser le déploiement de son infrastructure.
• - Et ensuite GitHub Actions pour la mise en œuvre de pipelines CI/CD.

 

Bicep : Une Evolution des templates ARM

Bicep est un langage déclaratif pour déployer ses ressources Azure. Cette évolution directe des templates Azure Resource Manager (ARM) offre une syntaxe plus claire, plus de modularité et du code réutilisable. Bicep supporte toutes les fonctionnalités proposées par les templates ARM. Dans notre exemple, un fichier principal main.bicep va définir la région et le groupe de ressource, puis appeler d’autres fichiers .bicep nécessaires à la création du compte de stockage, de l’API Management, du cluster AKS, etc..

 

Github actions : créer des pipelines pour automatiser la livraison de son code

GitHub Actions est un système d’intégration continue permettant d’automatiser les workflows de développement logiciel. Concrètement, GitHub Action va lire un fichier YAML contenant une série d’actions indépendantes à exécuter à la réception d’un événement (telle qu’une Pull Request). Les actions sont de différents types tels que Build, Test et Publish et fonctionnent peu importe le système d’exploitation. Un ensemble d’actions sont proposées par des développeurs tiers sur la marketplace GitHub.

Pour aller plus loin

Si vous souhaitez découvrir plus d’exemples de code avec Dapr, vous pouvez consulter le repository GitHub de la communauté Dapr. Pour rester au courant des nouveautés sur Dapr des « Community Call » sont organisés régulièrement sur YouTube pour présenter les dernières fonctionnalités.

Enfin, pour une étude plus complète de l’exemple Twitter Sentiment Processor, vous pouvez aller consulter cette vidéo de Philippe Beraud. Nous vous encourageons également à lire le livre blanc « Construire simplement et rapidement des applications distribuées avec Dapr » qui est également disponible ici.