Les fondamentaux d’Azure pour les développeurs

La conférence MS Experiences de Microsoft a été l’occasion d’entendre de nombreux retours d’expérience de consultants sur un large panel de technologies et d’architectures. C’est suite à cette conférence que je vous présente un petit retour sur la présentation de Pierre-Etienne Beau (Ai3), Louis-Guillaume Morand (MSC), Sébastien Mornas (MSC) et David Rozen (MSC) qui nous ont présenté la plateforme Azure et un éventail de ses outils.

Azure comprend près de 250 services aujourd’hui, ce qui peut être appréhensif !
Le fil rouge de cette présentation est une application permettant d’uploader une photo de son visage. Cet upload déclenche une fonction qui va appeler les services Cognitive d’Azure pour mettre à jour un écran de statistiques qui montre le nombre d’hommes et de femmes ainsi que la couleur des cheveux. Ces statistiques sont mises à jour sur la page en live grâce à Signal R.
Tout cela permet d’avoir un petit tour d’horizon des services proposés par Azure.

Adresse du site de démo: azurewebsites
Source code: github
Avec les slides: github

Historique du développement Cloud

Un peu d’histoire ! Avant le cloud, les développeurs n’avaient d’autre choix que de déployer leurs applications on-premises. Si cette solution existe toujours et reste toujours nécessaire pour certains cas, elle est complexe et coûteuse. Ces inconvénients ont mené à la création du IaaS (Infrastructure as a Service), où les applications étaient déployées sur des VM. Si cela a permis de réduire le coût, la complexité est encore présente dans la gestion de ces VM. L’abstraction a monté d’un cran dans le PaaS (Platfrom as a Service) qui permet de baisser la complexité en ayant à se soucier uniquement de la configuration de la plateforme cible pour recevoir nos applications. Cela a mené à de nouvelles architectures comme le serverless qui exploitent les capacités du cloud au maximum, ce qui permet aux développeurs de ne se soucier que du code, et d’abstraire l’intégralité de la gestion de la plateforme au gestionnaire cloud.

Pour résumer:

• On-premises : on crée les briques (serveurs, stockage, OS, logiciels) que l’on utilise et on les assemble.
• IaaS : création des briques dans des VM distantes pour amoindrir le coût.
• PaaS : les briques sont toutes faites, il faut encore les assembler !
• Serverless : assemblage simplifié, il faut juste faire un peu de configuration !

La configuration Azure

Et maintenant, le code ! Ou plus précisément, les clics dans le portail. À la base d’une architecture Azure se trouve le “Ressource Group”. Ce groupe a pour fonction de rassembler les briques d’une application au même endroit, et au sein d’une même zone et d’une même souscription.
Quid des zones et des souscriptions ? Azure laisse des choix à l’utilisateur sur la zone géographique dans laquelle il souhaite être hébergé. Ces zones peuvent rassembler plusieurs datacenters et sont jumelées pour faciliter la récupération en cas de souci matériel. À noter que depuis cette année, la France a deux zones à elle !
La souscription appartient à un compte Azure et rassemble des administrateurs et un moyen de paiement.

Ensuite vient l’App Service. Les app services sont des conteneurs à application, ils peuvent contenir un site ASP.Net, une application Java, un script Python, etc. À noter qu’ils permettent de mettre en place des “web jobs”, des sortes de tâches schedulées, hébergées au sein de l’application. Cela permet d’éviter de mettre en place toute une application de batch à part si l’on a besoin d’un simple batch en plus de son application.
Le déploiement de ces app services est intégré à VS, et permet le remote debug. Ces services sont autoscalés et auto-load balancés.
Il est possible de configurer la sécurité de plusieurs façons, que ce soit par auth, ASE, firewall ou restriction IP.
D’autres fonctionnalités comme les slots de déploiement pour déployer une app sur un slot pendant qu’elle continue de fonctionner sur un autre permettent de faciliter les tâches de déploiement.

Grâce au Ressource Group et aux App Services, on peut maintenant déployer notre site qui permettra d’uploader une photo et d’afficher la page de stats. Maintenant comment stocker les données ?
Grâce à un storage account, qui permet de rassembler des services de stockage persistants ou non. Les services principaux sont :

• Blobs : pour stocker les objets binaires principalement
• Files : pour stocker des fichiers et permettre aux applications liées de les voir comme sur un disque NTFS, utile pour les applications legacy
• Tables : pour stocker des données structurées
• Queues : pour stocker les messages

D’autres services de stockage existent hors du storage account comme CosmosDB, qui est une base de données documentaire NoSQL globalement répliquée, ou Azure SQL Database.

Etant donné que l’on va stocker des photos, on utilisera les blobs ! Les principales caractéristiques des blobs sont :

• Simple d’usage (REST API) ou SDK
• Sécurisé (key et SAS)
• Pay as you go
• Options avancées (Cold/hot storage, Immutable)

Une fois les photos stockées il faut les traiter, et c’est là qu’entrent en jeu les Azure Functions !
Ces fonctions exécutent du code suite à un trigger quelconque, on peut citer par exemple les Timers, les appels HTTP REST/WebHook, ou des événements déclenchés par d’autres services Azure (Blob, Queues, Service Bus, etc.)
Un code est ensuite exécuté, avec langage au choix : C#, F#, JavaScript (et bientôt PHP, Python, TypeScript, Bash)
Le résultat peut ensuite être simplement envoyé vers un autre service Azure (ou non).

Ces fonctions peuvent être écrites et publiées de deux façons différentes : depuis un IDE comme Visual Studio ou directement dans le portail Azure avec un éditeur. À noter qu’écrire une fonction avec VS bloque l’édition dans le portail.

Reste à reconnaître la personne. Comment coder la reconnaissance de la personne, de son sexe et de sa couleur de cheveux ? En demandant à une IA !
Azure intègre Cognitive Services qui permet d’utiliser l’intelligence artificielle clé en main par simple appel REST ! Comme beaucoup de services, le système est pay as you go et propose de nombreuses fonctionnalités souvent mises à jour.
Ces fonctionnalités s’orientent autour de 5 axes : vision, speech, recherche, langage et connaissance.

La dernière brique, assez récente, est le “Azure Signal R Service”. Petit rappel sur Signal R, c’est un framework Microsoft qui permet à un serveur d’envoyer des données à un client afin de mettre à jour les données d’une application en temps réel.
Le service Signal R Azure permet d’avoir une brique à laquelle les Azure functions, qui font abstraction du serveur, peuvent se connecter. La mise en place est très simple, il suffit de déclarer un Signal R service (2 tiers : gratuit/payant), de créer un push dans la function, et côté client, d’intégrer un package NPM et déclarer une connexion au service Signal R.

Conclusion

Au travers d’une petite application, on a pu voir une partie du large éventail de services offerts par Azure, de la création d’une API au stockage des données. Avec des outils comme le portail Azure et Visual Studio, le temps gagné pour créer et déployer une application est significatif, ce qui permet à chaque entreprise d’être à la pointe de la technique avec un coût maîtrisé.
Le revers de cette puissance qui est offerte à chaque développeur est que la maîtrise d’Azure est beaucoup plus complexe que de maîtriser un langage ou un framework, et demande une mise à jour presque quotidienne avec tous les services et améliorations mis en place par Microsoft.

Si cela ne vous fait pas peur, je vous invite à regarder le code pour plus de détails !

© SOAT
Toute reproduction est interdite sans autorisation de l’auteur.