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. Particularités d’une architecture Serverless
  2. Retour sur les avantages et inconvénients sur Serverless Computing
  3. Serlerless, pour qui ?

 

Explications : 

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.  

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) 

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. 

 

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 lorsquelle est gardée en mémoire et prêt à être exécuté.  

Agnostique 

En théorie, à l’instar des applications microservices, les fonctions sont elle 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.  

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