Serverless, FaaS, de quoi s’agit-il ?  

Le Serverless est avant tout un modèle Cloud Natif qui permet d’aller plus loin dans cette envie de scalabilité, d’optimisation des coûts et de réduction du « time-to-market ». 

Dans cet article, nous verrons :

1. Qu’est-ce qu’une architecture serverless
2. Les particularités d’une architecture Serverless
3. Retour sur les avantages et inconvénients sur Serverless Computing
4. Serverless, pour qui ?
5. Quel est le coût d’une architecture Serverless ?
6. Quel lien entre le Serverless et les Microservices ?

Qu’est ce qu’une architecture Serverless ?

Dans un hébergement plus classique, on a l’habitude de développer et déployer les applications informatiques sur des serveurs qu’il faut donc gérer, provisionner et dont il faut gérer les ressources. Même quand ils ne sont pas nécessaires en tant que tels, les serveurs doivent être maintenus. Faire en sorte qu’ils restent disponibles et à jour reste à la charge de l’entreprise. Dans le cas d’une montée en charge, toute la mécanique doit être gérée en interne soit au travers du déploiement de nouvelles machines ou conteneurs (dé-provisionnés lors de la baisse de charge) au travers de mécanismes plus ou moins automatisés (scripts, orchestrateur, scale-set etc…).  

Dans l’architecture Serverless, il n’y a plus de notion d’infrastructure en tant que telle. Tout est pris en charge par le fournisseur Cloud. Le Serverless s’affranchit donc des contraintes évoquées plus haut et de ces limites en décorrélant l’écriture (et le déploiement) du code de l’infrastructure sous-jacente. Concrètement, les développeurs conçoivent leur code sous forme de fonctions sans état, qui contiennent les informations nécessaires à leur exécution sans se soucier de leur hébergement. Voilà pourquoi on parle de Serverless.  

Les fonctions seront, cependant, bien au final hébergées dans les serveurs du fournisseur Cloud. Celui-ci ne fournit son service que lorsque la fonction est requêtée. Cela veut dire que le fournisseur est responsable autant des serveurs que de l’exécution du code qu’il héberge. Cela veut dire également qu’il ne facture qu’à l’utilisation réelle de la fonction et non plus à la quantité de bande passante ou au nombre de serveurs.  

Pour conclure sur cet aspect, le Serverless Computing permet de ne payer qu’à l’utilisation ce qui permet d’optimiser les coûts liés à l’infrastructure. Outre ce gain direct, l’équipe de développement peut avec ce type d’architecture se concentrer entièrement sur les tâches à forte valeur : le développement de l’application. 

Le cas des Azure Functions

Le Serverless est aussi souvent appelé FaaS (Function As A Service). Des fonctionnalités offertes par tous les grands fournisseurs Cloud. Chez Microsoft, sur Azure, on parle d’Azure Functions dont on retrouve l’équivalent chez AWS (AWS Lambda) ou chez Google Cloud (Cloud Function).  

Le Serverless apporte de nombreux bénéfices pour le déploiement d’applications web comme la scalabilité, la disponibilité, le fait d’avoir une granularité très fine sur les coûts et bien entendu l’absence de gestion des serveurs.

Les Azures Functions sont étroitement liées à l’architecture Serverless. Dans une architecture de ce type, vous n’avez plus besoin de gérer les serveurs sous-jacents, c’est le fournisseur Cloud responsable de l’exécution du code hébergé qui s’en occupe. Cela implique de structurer votre application sous forme de fonctions exécutées à la demande. Les Azure Functions, c’est donc une implémentation de la notion de Serverless par Microsoft sur la plateforme Azure.

Microsoft a implémenté, sur sa plateforme Azure, une fonctionnalité qui permet de résoudre la problématique liée au Serverless, le Stateless (les développeurs conçoivent leur code sous forme de fonctions sans état). Il s’agit de Durable Functions, une extension permettant d’écrire des fonctions avec état.

L’extension gère l’état, les points de contrôle et les redémarrages à votre place. Vous n’avez pas besoin d’implémenter votre propre mécanisme de suivi de l’état, ce qui vous permet de vous concentrer sur votre logique métier.

Ces deux aspects constituent en eux-mêmes une petite révolution.  

Particularités d’une architecture Serverless 

Event-driven 

L’exécution de la fonction peut être déclenchée par des événements métiers : requêtes http, événements de base de données, service bus, alertes ou encore tâches planifiées.   

Ces évènements peuvent être déclenchés de façon synchrone comme asynchrone.  

Stateless 

Les fonctions ne sont pas « permanentes », elles ne sont appelées que lorsque l’on en a besoin et chaque requête est indépendante. Par exemple, il n’est pas possible de suivre un workflow. Pour pallier cela, Microsoft a mis en place les Durable Functions, une extension qui permet de gérer l’état.  

Cold Start 

Puisque les fonctions ne sont exécutées qu’à la demande, il peut y avoir une latence dûe au démarrage lors de l’exécution. D’autant plus lorsque la fonction n’est pas appelée régulièrement. On parle alors de Cold Start à différencier du Warm Call lorsqu’elle est gardée en mémoire et prêt à être exécuté.  

Agnostique 

En théorie, à l’instar des applications microservices, les fonctions sont elles aussi agnostiques quant aux technologies utilisées. Cela peut permettre l’utilisation de technologies appropriées ou plus performantes pour tel ou tel évènement.  

En pratique, il faut vérifier les langages pris en charge auprès de votre fournisseur de Cloud, en dehors des langages natifs. Un sujet sur lesquels ces derniers ont fait un certain nombre d’avancées. Par exemple, en dehors du C# et du F#, les Azure Functions acceptent également le JavaScript, Java, PowerShell, Python et TypeScript.  

Service Bus

Les Services Bus permettent de connecter des fonctions entre elles soit des fonctions avec d’autres services Cloud ou locaux. Une solution idéale lorsque l’on souhaite mettre en place de la communication entre systèmes et lorsque l’on souhaite mixer les architectures.  

Retour sur les avantages et inconvénients du Serverless Computing 

La mise en place des fonctions ServerLess n’est pas anodine. Elle nécessite parfois de repenser l’application totalement ou en partie afin de la « découper ». Un processus équivalent lorsqu’on met en place une architecture microservices.  

A ce titre, lorsque l’on décide d’implémenter une architecture Serverless, il n’est pas nécessaire que toute l’application soit concernée. On peut décider, lorsque c’est pertinent (car c’est possible ou car c’est intéressant financièrement), de ne découper en « fonctions » qu’une seule ou plusieurs parties d’une application.  

Avantages 

Optimisation des coûts :  

Comme évoqué plus haut, le Serverless permet de faire coïncider dépenses et utilisation. C’est simple : à chaque fois que la fonction est appelée, on paye ; si la fonction n’est pas appelée, on ne paye pas. Alors qu’une autre architecture implique le coût d’un serveur, utilisé même partiellement, on s’imagine bien l’optimisation des coûts que cela peut engendrer.  

Attention, Serverless ne rime pas nécessairement avec réduction systématique des coûts. Cela dépend avant tout de l’utilisation que l’on va en faire. Si une fonction est fortement utilisée, le coût peut être similaire à une autre approche. 

Scalabilité : 

Le fournisseur de la solution Cloud offre un dimensionnement à la demande et en temps réel. La fonction doit répondre quand elle est appelée, même en cas d’une augmentation très importante des requêtes. Des notions de Quotas quotidiens existent cependant pour se prémunir si besoin d’une « explosion » imprévue des usages 

Time-to-market :  

Très rapidement l’équipe de développement peut déployer de nouvelles fonctionnalités, optimiser le code ou corriger des erreurs et ce sans nécessiter de configurations au niveau de l’infrastructure. Ces évolutions ou corrections peuvent concerner, au choix, une ou plusieurs fonctions. Les déploiements sont donc beaucoup moins lourds et plus rapides. 

De plus, à l’instar des microservices, une modification sur une fonction se fait de manière totalement indépendante et n’impacte en rien les autres fonctions ou le reste du logiciel. 

Simplification des développements : 

Chaque fonction formalise, en elle-même, une requête bien précise. On peut aller un peu plus loin en créant des fonctions très simples n’ayant qu’une seule finalité.  

Inconvénients 

Dépendance au Cloud Provider 

La visibilité sur l’infrastructure (machines virtuelles, environnement, process, etc.) est très limitée. Cela peut poser problème lorsque l’on souhaite tester l’application dans un environnement similaire à celui dans lequel il sera déployé.  

Cela peut poser également problème si l’on souhaite avoir une solution « bi-céphale » OnPremise et Cloud, ou migrer vers un autre fournisseur de FaaS, d’autant plus que cela peut impliquer de réécrire certaines fonctions. 

Sécurité 

Bien que l’on délègue la gestion des serveurs, il faut faire attention à ne pas négliger les aspects de sécurité, notamment lorsque l’application traite des données sensibles ou des données personnelles. Il est donc nécessaire d’avoir quelques garanties sur la sécurité des données et sur la gestion du multitenancy des serveurs. 

Lire aussi | Cloud native : répondre aux enjeux de sécurité 

Serverless, pour qui ?  

La technologie Serverless est encore jeune mais elle est flexible et, au fur et à mesure de son évolution, les cas d’utilisations se font plus nombreux.  

Il faut tout d’abord penser que tout n’est pas noir ou blanc. L’architecture Serverless ne doit pas s’appliquer nécessairement à toute une application. Si c’est pertinent, seule une partie de l’application peut être concernée.  

Quelques cas d’utilisations : 

• Comme évoqué précédemment, une architecture Serverless s’adapte idéalement à des logiciels ou des tâches event-driven.  
• Du côté de la demande, le Serverless a toute sa place lorsque l’utilisation du logiciel ou de certaines requêtes est très variable ou lorsqu’il est difficile d’anticiper les pics de demande, comme cela peut être le cas avec les ChatBots.  
• APIs : le Serverless permet d’exposer rapidement ses APIs et sans contraintes 
• Applications IoT 

Quel est le coût d’une architecture serverless ?

Les dépenses liées au serverless, sont calculées à l’exécution du code et uniquement pour le temps de consommé. Le Serverless permet de faire coïncider dépenses et utilisation donc, en théorie, c’est moins cher puisque l’on ne paie que lorsque la fonction est appelée. Par exemple, AWS facture son service Lambda tous les 100 ms. Le prix varie selon le nombre de fois où se déclenche le code

Cela étant dit, Serverless ne rime pas nécessairement avec réduction systématique des coûts et peut nécessiter un investissement de départ.

En effet, les applications Serverless nécessitent des langages de programmation spécifiques et parfois un remaniement du code existant, potentiellement coûteux.

Sans oublier l’impact des coûts annexes :

• API Gateway : le code des applications FaaS est généralement publié et consommé via des appels API
• Application Load Balancer : moins riche en fonctionnalités que API Gateway mais sensiblement moins cher
• CloudFront : configurer du cache permet de réduire le nombre d’appel a votre Lambda

Les startups, beaucoup moins affectées par la refactorisation du code existant, peuvent clairement tirer un bénéfice rapide et à long terme de l’utilisation du serverless.

Cela étant dit, il est néanmoins possible d’optimiser le cout de la manière suivante :

• Augmenter la mémoire de la lambda allouée pour un CPU plus performant – Optimiser le cold start : les temps de réponse impactent la facture
• Limiter les logs inutiles : uniquement en cas d’erreurs
• Faire attention au cout de stockage et de transfert : la taille de la lambda impacte le cold start

Quel lien entre le Serverless et les Microservices ?

La multiplication du nombre d’applications (et leur mode de consommation) milite dans le sens d’architectures permettant les évolutions et les déploiements accélérés de celles-ci.

Microservices et Serverless en font partie. Elles partagent certaines caractéristiques et sont complémentaires.

Un microservice est une partie d’un système, qui fonctionne à petite échelle pour répondre à des règles métiers distinctes. L’architecture Serverless, s’affranchie de la couche serveur et s’adosse à des fonctions.

Un microservice est plus grand qu’une fonction mais peut être équivalent à plusieurs fonctions serverless.

En matière de microservices, le focus est souvent mis sur les technologies, alors que le point clé consiste à bien définir le contour des services et de faire en sorte que chaque microservice ait la charge de répondre à un problème et uniquement à celui-ci. C’est donc plus facile de travailler sur un projet existant car on identifie plus facilement les liens entre les différents services.

Les microservices sont également une bonne option si vous souhaitez migrer une application monolithique vers une architecture plus moderne ou si vous souhaitez basculer d’un mode OnPremise vers le Cloud.

Le serverless quant à lui s’applique plus particulièrement aux applications qui:

• nécessitent un déploiement rapide
• sont pilotées par des événements
• portent sur une tâche planifiée et dont l’exécution ne prendra que quelques secondes

Mise en pratique | Migration cloud : pourquoi et comment ?