Comprendre les limitations du serverless pour en tirer un maximum d'avantages

Selon Gartner, d'ici à 2025, 50% des entreprises dans le monde auront déployé un modèle serverless, contre seulement 20% aujourd'hui.

Le serverless s'applique à une large gamme de produits cloud qui permettent aux développeurs et aux entreprises de ne plus se soucier de la gestion de leurs infrastructures lors de l'exécution de services (en utilisant des functions ou des containers) ou même du stockage de données (dans des bases de données ou avec object storage). Ainsi, le serverless s’apparente à une extension du modèle de Platform-as-a-Service qui permet aux développeurs de se concentrer sur la création d'applications. Cependant, dans la plupart des cas, ces plateformes connectent toujours l’application à un serveur, ce qui limite sa scalabilité et génère des coûts fixes. Les conteneurs virtuels, tels que Dynos de Heroku, permettent aux développeurs de déployer et d’exécuter leur code facilement, mais ils ne sont pas capables de scaler à zéro et l'auto scaling a une tarification plus élevée.

Une grande capacité de mise à l'échelle, un paiement à l'usage, de la flexibilité, aucune gestion de serveurs... Le serverless peut apparaître comme la solution idéale pour lancer toute application utilisant des microservices et une architecture orientée événements (EDA).

Cependant, au moment de mettre en place de telles applications, la situation n’est guère réjouissante. Comme le décrit D. Zimine dans un article, "rien n’est gratuit dans un système fermé : on ne peut pas faire d’omelette sans casser des œufs". Qu’il s’agisse de gérer la latence (démarrage à froid) ou de déployer facilement plusieurs fonctions en même temps, les développeurs et la communauté serverless ont dû créer de nouveaux outils, processus et pratiques afin de contourner les limitations des fournisseurs.

Même si, dans bien des cas d’usage, le serverless fonctionne à merveille, ce n’est pas une solution magique. Soyons concrets et analysons les principaux arguments de vente du serverless.

Aucune gestion de serveurs

Comme son nom l’indique, avec le serverless les développeurs n’ont pas à gérer leurs serveurs. Tout est pris en charge par le fournisseur de cloud, depuis les mises à jour système jusqu’au contrôle d’accès, en passant la mise à l'échelle et la redondance des serveurs… Il y a bien de véritables serveurs derrière les plateformes serverless, mais ils sont partagés entre les utilisateurs en toute sécurité. Les fournisseurs de cloud gèrent les infrastructures et la sécurité (notamment pour éviter toute perturbation ou pire, toute attaque entre utilisateurs).

Le principal inconvénient de l’abstraction des serveurs est que les utilisateurs ont l’impression de perdre le contrôle de leur code et de leurs données, car ils ne savent pas où ni comment ils sont exécutés et traités. D’après le sondage sur le thème du serverless réalisé par O’Reilly en 2019, le principal obstacle à l’adoption de serverless par les entreprises semble être un sentiment d’insécurité. Ceci dit, ces dernières peuvent tout à fait choisir des fournisseurs qui déploient leurs solutions serverless dans des environnements isolés et sécurisés, garantissant une haute disponibilité.

Scalabilité

Depuis quelques années, les outils open source orientés serverless tels que Kubernetes (orchestrateur de conteneurs) et Firecracker (micro VM) se font de plus en plus nombreux. Ils permettent aux utilisateurs d’étendre leurs infrastructures en fonction du trafic. Grâce à ces solutions, les services de calcul serverless peuvent exécuter du code ou des applications conteneurisées en fonction des pics de trafic. Ces services fonctionnent avant tout grâce à la mutualisation et à l’optimisation système qui peuvent scaler à zéro en moins d’une demi-seconde.

La scalabilité n’est ni infinie, ni immédiate. Même si la mutualisation et la conteneurisation des serveurs permettent de masquer cela à l’aide de nœuds fonctionnant en continu, capables de lancer rapidement de conteneurs afin de répondre à la demande. Cependant, il y a bien des serveurs derrière serverless, et leur fonctionnement dépend de leurs capacités physiques à être arrêtés ou lancés. Par ailleurs, le regroupement des ressources ne peut se faire sans que les fournisseurs de cloud ne soient capables d’offrir la même expérience à tous les utilisateurs partageant un même nœud. Cela implique la mise en place de quotas limitant la capacité de mise à l’échelle des applications.

Flexibilité

Si nous réduisons le serverless à Function-as-a-Service (FaaS), alors, en divisant chaque service en un ensemble de fonctions, le serverless permet de créer des systèmes à base de microservices où chaque composante peut être managée indépendamment (simplifiant par exemple les mises-à-jour), mais aussi absorber indépendamment les pics de trafic. Par exemple, même si les systèmes de facturation ou de connexion d’un site web reçoivent de nombreuses requêtes, cela n’aura pas de conséquences sur les systèmes de notification ou le système de gestion des données des utilisateurs, qui sont peu utilisés.

Cependant, cela implique une complexification des architectures, car chacun des services ou fonctions se trouve réduit à une opération basique et unique, dont la logique dépend du middleware ou de services tiers (file de messages, moteur de workflow…). Cela risque de transformer les applications serverless en véritables sacs de nœuds. Malgré tout, certains voient dans cette contrainte le signe d’un problème culturel, et affirment que l’approche serverless met en lumière un besoin de changement dans la conception des applications, depuis la création de services à la consommation de services et du code à la configuration.

Une gestion simplifiée

Comme beaucoup de services managés, le serverless fonctionne selon une approche plug and play : "Fournissez le code ou le conteneur, et on s’occupe du reste". Pour les conteneurs, un environnement isolé sur une solution serverless est plus facile à gérer qu’un cluster Kubernetes, par exemple. Choisir un fournisseur ou un système offrant une API claire et proposant une interface utilisateur intuitive peut aider au déploiement.

Rapport coût-efficacité

Grâce aux économies d’échelle et à la mutualisation des serveurs, les fournisseurs de cloud offrent la possibilité d’une mise à l’échelle à zéro. Cela signifie que seul leur control plane tourne tandis que les applications des clients sont en veille, prêtes à traiter les demandes entrantes. En optimisant leurs applications pour le serverless, les développeurs peuvent construire des applications dont chaque service évolue de manière indépendante et dont les dépenses sont vraiment liées aux usages. C’est en partie pour ces raisons que les entreprises ont commencé à s’intéresser au serverless.

Cependant, le rapport-coût efficacité dépend du cas d’usage. Le serverless est recommandé pour les tâches asynchrones et faciles à paralléliser, dont les charges sont imprévisibles. Cela rend le serverless attractif pour créer de nouveaux services, en particulier pour les petites équipes qui n’ont pas les moyens de gérer leurs propres infrastructures, mais qui peuvent néanmoins supporter le coût supplémentaire que représente le serverless. En revanche, cette solution peut paraître moins pertinente pour les entreprises plus chevronnées qui préfèreront investir dans un système qui leur appartient et qu’elles contrôlent (comme un système s’appuyant sur Kubernetes, par exemple). Les entreprises doivent être prudentes : puisque les produits serverless sont facturés à l’usage, les coûts peuvent être imprévisibles selon l’utilisation du service. Il est donc important de surveiller les coûts, ou de limiter la capacité de mise à l’échelle de vos fonctions.

Finalement, le serverless en vaut-il vraiment la peine ?

Bien plus qu’une tendance, le serverless est véritablement en train de transformer la façon dont les applications sont conçues et exécutées, tout en éliminant le stress opérationnel lié à la gestion de l'infrastructure. Mais cela a un prix : faire confiance à un tiers pour effectuer le travail de fond. Les développeurs doivent tenir compte de leurs cas d’utilisation potentiels, mais aussi des moyens et des besoins de leur entreprise avant de prendre une décision concernant les services serverless. Lorsque ce modèle est utilisé de manière efficace, il devient possible de créer des services innovants en exploitant ses avantages, mais aussi adaptés à ses contraintes.