Êtes-vous prêts à passer à une architecture serverless ?

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 Laurent Grangeau centrée sur l’architecture serverless.

Présentation serverless

Le serverless n’est pas un nouveau service cloud, c’est une tendance d’architecture qui se base sur la composition de services cloud tels que aPaaS, xPaaS, et surtout FaaS afin d’abstraire complètement la gestion des serveurs et de l’infrastructure de bas niveau, qui seront prises en charge par le cloud provider.

Ce type d’architecture sera de fait scalable et résiliente par défaut, et permet de découper l’application en services granulaires, à l’instar d’une architecture micro-services.

Les avantages principaux sont :

• Les développeurs doivent juste s’occuper du code. Pas de gestion de l’infrastructure.
• Plateforme éphémère qui attend juste les requêtes et instancie les fonctions à la demande. Ces fonctions ne vivent que le temps de délivrer un résultat.
• De fait l’architecture est scalable à zéro, pas d’utilisation du service, pas de coût pour le client.
• Scalabilité et résilience par défaut grâce au cloud
• L’application est découpée en services granulaires

On a tout de même des contraintes :

• Les fonctions sont stateless, et doivent prendre peu de temps à s’exécuter (concept de plateforme éphémère, Azure par exemple limite le temps d’exécution des fonctions)
• Cold start, il vaut mieux faire la première requête soi-même car elle prendra un certain temps, le reste des appels étant en revanche rapide
• Vendor lock-in, une fonction AWS est différente d’une fonction Azure
• Oblige à rapatrier la sécurité au niveau applicatif, impossible de juste mettre un firewall

Les services FaaS (Function as a Service) sont un composant majeur du serverless. Ce type de service cloud permet à des développeurs d’exécuter du code en réponse à des événements sans se soucier de l’infrastructure sur laquelle ce code sera exécuté. Le FaaS utilise plusieurs patterns pour permettre d’exécuter les fonctions en réponse à un événement :

• HTTP API Gateway : une requête HTTP reçue par une gateway déclenche directement une fonction
• Message Stream : un message reçu par un outil comme Kafka ou Kinesis déclenche une fonction
• Async Message Queue : un message placé dans une message queue déclenche une fonction
• Job (Master/Worker) : un job est placé dans une “priority queue” lue par un master qui déclenche les fonctions nécessaires

L’Offre Azure

Afin d’implémenter une architecture serverless, Azure offre de nombreux services pour chaque besoin :
Compute → Azure functions
API Proxy → Azure API Management
Storage → Azure Storage
Datastore → Azure CosmosDB
Messaging → Azure ServiceBus
Orchestration → Azure Durable functions
Analytics → Azure Log Analytics

Quelques précisions sur les Azure Durable Functions : elles sont importantes car elles ont la particularité de permettre à plusieurs fonctions de partager un état entre elles :

• Chained functions
• Fan-in/Fan-out
• Async
• Monitoring
• Human interaction (ex : envoi d’une requête d’approbation par une function, si l’humain répond cela déclenche fonction d’approbation, si pas de réponse dans les 24 heures fonction d’escalade)

L’architecture serverless crée de nouvelles limitations comme dit plus haut. En plus de ces limitations, elle change la façon de gérer certaines étapes du cycle de développement et de déploiement d’un projet.
Par exemple :

• Testing en local et unitaire des fonctions : tester une fonction dans le cloud peut se révéler difficile, utiliser une approche TDD et l’IoC permettent de tester plus facilement. Microsoft propose également des outils comme “Azure functions core tool”, qui permet d’émuler les conditions de déclenchement d’une fonction en local, ou encore CosmosDB emulator si la fonction fait appel à CosmosDB.
• CI/CD : les déploiements sur infra cloud sont simplifiés par Azure DevOps qui permet de gérer tout le pipeline CI/CD sur Azure directement
• Monitoring : l’architecture serverless fait changer les KPI, on ne regarde plus les mêmes données. Au lieu de la santé des serveurs, il faudra regarder le nombre moyen d’appels par seconde ou encore le temps mis par appel. Ce monitoring est simplifié par Azure Monitor
• Télémétrie : comme les fonctions sont exécutées sur le cloud et sans serveur dédié, il est nécessaire de pouvoir accéder aux fonctions appelées, au temps passé et aux logs complets facilement. Azure Analytics permet de récupérer et requêter les logs très rapidement. À noter qu’il est utile de grouper les logs par “Role instance” pour faciliter la lecture des logs dans ce genre d’architecture

Des outils Azure actuellement en preview permettent de simplifier la gestion des fonctions en API et de leur déploiement :
Les Slots permettent de déployer les fonctions et autres applications sur des environnements intermédiaires. Une fois ces environnements prêts, le slot sur lequel les applications tournent est échangé par le slot intermédiaire. Cela permet de déployer une nouvelle version avec virtuellement aucun downtime ! À noter que préchauffer le slot intermédiaire avant l’échange peut être nécessaire pour éviter une dégradation des performances pour le client qui aura le malheur de faire le premier appel. Plus d’informations ici :

Configurer des environnements intermédiaires dans Azure App Service
Deployment Slots Preview for Azure Functions

Les Proxies permettent de versionner l’application et de présenter une API unifiée en ayant plusieurs applications de fonctions. Des fonctions de modification de requête et/ou de réponse sont également présentes.

Utilisation d’Azure Functions Proxies

Pour permettre des déploiements plus efficaces, il existe également des frameworks afin de déployer toute son infrastructure avec juste du code, on peut citer :
Azure Ressource Manager
Terraform
Serverless (framework)

REX de M. Grangeau

Le contexte du projet :
Un client dans le transport possède un système ESB (médiation) sur machine AWS qui écoute des messages, les transforme et les renvoie. La licence est coûteuse et prend fin dans un an. L’ajout de flux est compliqué, prend plusieurs semaines et est coûteuse pour le métier.
Le client a besoin d’une nouvelle application, avant l’expiration de la licence dans 1 an, qui permette l’ajout de flux simplement et rapidement et qui soit moins chère à l’exploitation. C’est un système critique, donc avec un SLA > 99% et une disponibilité 24/7.

Première solution proposée :

Cette solution a été rejetée car trop complexe. Laurent et son équipe avaient intégré de nombreuses briques, avec un cœur basé sur API Management, Service Bus et les Azure Functions.
Suite à la simplification, cette solution a été retenue :

Le tout est monitoré dans Azure Monitor, mais comme le client utilise Zabbix, l’équipe a mis en place un connecteur pour envoyer les données Monitor dans Zabbix.
La sécurité se base sur Azure Key vault et Azure AD, l’AD Azure est lié à l’AD du client.
La partie DevOps est basée sur Maven et Jenkins, tous les déploiements sont automatiques sauf la production.

Résultat :

• Les deux premiers flux sont disponibles en moins de 5 mois, entre la spécification du besoin en Agile et la mise en production
• Coût total du projet : 50% moins cher qu’on-premises (environnement AWS inclus)
• Ajout de nouveaux flux en 3 jours

Un client convaincu et qui a adopté le serverless pour tous ses nouveaux projets !

Conclusion

Les avantages de l’architecture serverless comme le modèle pay-as-you-go, l’infrastructure entièrement cloud et la scalabilité à zéro entraînent des gains de coûts et de performance non négligeables. Avec cela des limitations nous sont imposées comme la programmation stateless, qui peut être casse-tête, et de nouvelles pratiques opérationnelles à adopter.
Azure offre des services qui facilitent cette mise en place.
Si le serverless vous intéresse, n’hésitez pas à vous faire la main avec quelques fonctions pour vous familiariser avec cette architecture avant peut-être de l’adopter pour vos futurs projets !

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