Le serverless est une innovation relativement récente. En substance, il fournit une couche d’abstraction entre les ressources des serveurs et les fonctions qu’elles offrent, et on l’appelle parfois fonction en tant que service (FaaS).
Les fonctions du serveur sont fournies via le cloud afin de permettre de concevoir et d’exploiter des applications de manière plus simple et plus économique. Cela facilite l’exécution de tâches associées aux serveurs, comme le provisionnement, la mise à l’échelle et la gestion de l’infrastructure nécessaire à l’exécution de l’application.
Ces fonctions sont déchargées des utilisateurs finaux et s’exécutent automatiquement en arrière-plan. Cela simplifie considérablement l’allocation des ressources et permet notamment aux développeurs de se concentrer sur leurs tâches essentielles, plutôt que de chercher à comprendre l’infrastructure sous-jacente nécessaire à l’exploitation et à la prise en charge de leurs applications.
Voici quelques-unes des principales tendances du marché du serverless :
1. La croissance du serverless
Le serverless est populaire : 50 % des utilisateurs d’AWS interrogés en 2020 ont déclaré utiliser des fonctionnalités serverless, à un degré ou à un autre.
Ce chiffre a fortement augmenté au cours des deux dernières années.
Selon les estimations actuelles, la valeur de ce marché en pleine évolution atteint environ 8 milliards de dollars US, contre 1,9 milliard de dollars US en 2016.
2. Des applications plus rapides
Si tant de personnes se tournent vers le serverless, c’est notamment parce qu’il leur permet de concevoir des applications plus rapidement.
Comme le serverless élimine la nécessité de gérer l’infrastructure sous-jacente, les personnes chargées de créer les applications ne sont plus distraites par des tâches telles que le codage associé aux ressources de stockage et de calcul.
« Cette approche simplifie considérablement le processus de création et de déploiement des applications, car elle permet aux développeurs de se concentrer davantage sur la valeur au cœur de l’entreprise, d’accroître leur productivité et de commercialiser leurs produits plus rapidement, puisque les tâches d’infrastructure sont abstraites », a déclaré Naina Singh, responsable principale de la gestion des produits chez Red Hat.
« Les fonctions serverless vont encore plus loin en éliminant le code réseau habituel et les autres éléments de code standard généralement nécessaires aux applications cloud natives ».
3. La mise à l’échelle dynamique
La mise à l’échelle dynamique est elle aussi une tendance qui stimule l’adoption du serverless.
Les utilisateurs du serverless constatent qu’il facilite une mise à l’échelle plus simple et plus dynamique.
Par exemple, le framework open source Knative est utilisé par de nombreux fournisseurs de solutions serverless, notamment Red Hat OpenShift Serverless.
Il propose une solution serverless basée sur des conteneurs, par-dessus Kubernetes. Ainsi, la mise à l’échelle peut s’effectuer en fonction de la demande réelle des utilisateurs, en passant de zéro et en y revenant avec une relative facilité.
4. La maîtrise des coûts
Le serverless peut parfois constituer un moyen judicieux de maîtriser les coûts d’infrastructure.
Comme il repose sur un modèle de paiement à l’usage, les développeurs et autres utilisateurs peuvent constater qu’il revient moins cher d’acheter des ressources serverless que de maintenir une quantité fixe de serveurs.
Si les ressources de calcul ne sont nécessaires que pendant une courte période, pourquoi créer en interne une infrastructure de support ? Cela ouvre également la voie à une plus grande indépendance des processus.
En isolant les différentes parties de l’application à l’aide du système événementiel du serverless, les bugs et autres problèmes restent cantonnés à une zone localisée. Cela peut être d’une grande aide pour les développeurs.
5. Sans état, oui ; avec état, non
Le serverless ne convient pas à tous les cas d’usage.
Les cas d’usage sans état sont les plus adaptés à une architecture serverless, a déclaré Singh, de Red Hat.
« Si l’approche serverless convient parfaitement aux applications sans état, il faut déployer des efforts supplémentaires pour permettre à des applications avec état (par exemple pour stocker l’état d’une session en mémoire entre deux requêtes) de fonctionner de manière serverless, ce qui n’est pas toujours possible », a déclaré Singh.
« Les cas d’usage sans état sont les plus adaptés à une architecture serverless, ce qui oblige les utilisateurs à gérer l’état par d’autres moyens. »
Les applications présentant des caractéristiques d’accès non uniformes et des profils de trafic très variables sont elles aussi bien adaptées aux environnements serverless.
Si l’entreprise doit faire face à des pics saisonniers et ponctuels, comme pendant les fêtes ou lors de la publication de résultats financiers, le serverless peut réduire les coûts, puisque l’entreprise ne paie que pour cette courte période d’utilisation.
C’est pourquoi les start-up semblent se tourner massivement vers le serverless. À leurs débuts, elles cherchent souvent à éviter de payer pour du matériel. Le serverless leur permet de créer des applications, puis de constituer une base de clients générant suffisamment de revenus pour financer le développement d’une infrastructure interne.
« Un cas d’usage idéal du paradigme serverless concerne les applications présentant des caractéristiques d’accès non uniformes et un trafic en pics », a déclaré Singh.
« Par exemple, une boutique qui vend des cartes de Noël n’aura pas à payer sa boutique en ligne lorsqu’elle n’est pas utilisée pendant l’été. Les applications serverless sont également idéales pour expérimenter ou explorer une idée de start-up, car les coûts de déploiement sont directement corrélés au volume d’utilisation, ce qui réduit le risque lié à l’investissement. »
Les entreprises des secteurs fortement réglementés devraient toutefois probablement éviter le serverless, car son architecture mutualisée peut poser des problèmes de conformité. Une seule mauvaise configuration suffit pour qu’une exposition des données ou d’autres problèmes de sécurité ou de conformité se produisent.