Le Serverless ne convient pas à toutes les applications
Même si les plateformes dites Serverless ont la capacité de réduire à la fois la complexité de l’infrastructure et les coûts, elles ne constituent pas la meilleure option pour certaines applications, comme celles exploitant les mécanismes du multi-cloud.
Pour une entreprise, les critères qu’il convient d’évaluer avant de se plonger dans le Serverless sont nombreux. Chaque API a des exigences distinctes ; il est donc difficile d’identifier celles qui sont ou ne sont pas éligibles aux infrastructures dites Serverless. En général, on parle de Serverless (littéralement sans serveur) pour illustrer qu’une application se repose sur des services cloud, invoqués de façon éphémère et sur lesquels s’appuient certaines fonctions logiques. Le développeur exécute son code au sein de ces Faas (Function-as-a-service) à la demande.
Il existe toutefois plusieurs méthodes pour identifier si un back-end Serverless est la bonne solution pour une application, quand cela est pertinent et pourquoi cela devient pertinent. Réduire la complexité et rationaliser l’infrastructure sont généralement deux motivations clé.
Réduire la complexité
Les API sont complexes par nature. Leur utilisabilité mise à part, elles restent des composants à géométrie variable. Du stockage de données à la logique métier, les éléments à prendre en compte sont nombreux. Si l’on écarte les grandes API de logiciels monolithiques, les plateformes Serverless constituent un bon moyen pour réduire la complexité d’une application et au final de l’ensemble de l’entreprise.
A l’inverse des grandes applications, celles s’adossant à une architecture composée de microservices sont logiquement les premières éligibles à ces infrastructures Serverless. La migration d’une telle application vers un backend Serverless permet aux développeurs de minimiser le nombre de ces microservices et de rationaliser encore plus les endpoints. Résultat, le coût de l’infrastructure se retrouve lui-aussi abaissé, car chaque fonction Serverless fonctionne à la demande – et est donc facturée en fonction de l’usage.
Comme les applications en microservices, les API qui définissent une fonction unique sont idéales pour le Serverless. Leur empreinte réduite permet de les encapsuler dans des fonctions elles-mêmes plus ciblées et donc plus petites.
Rationnaliser l’infrastructure
Par définition, avec les plateformes Serverless, l’entreprise n’a plus à se préoccuper des serveurs de l’infrastructure – comme tout ce qui est placé dans le Cloud finalement. Cela procure donc un effet de liberté chez les développeurs qui peuvent rationaliser aussi bien la taille de leurs équipes que le nombre d’API – le tout avec des coûts plus bas.
Le Serverless permet également de simplifier le dimensionnement. Les API, dont l’usage nécessite un dimensionnement aléatoire, conviennent à ces plateformes qui sont capables de gérer ces demandes imprévisibles. En éliminant ainsi cette contrainte, celle d’avoir à gérer les ressources de l’infrastructure, le Serverless permet de consacrer plus de temps à créer des API plus robustes et optimisées.
Toutefois, le mode du Serverless est généralement associé au verrou-vendeur. En gros, les infrastructures Serverless conviennent mieux à des applications et des API qui se reposent déjà sur la même plateforme Cloud. Les API que l’on héberge soi-même et qui s’adossent à des socles génériques de virtualisation n’auront pas accès à l’une des promesses du Serverless : une intégration simplifiée entre les autres services Cloud de la même plateforme du même fournisseur.
Quand il ne faut pas choisir d’infrastructure Serverless
Si les plateformes Serverless peuvent réduire la complexité et les coûts, elles ne conviennent pas à toutes les applications et toutes les workloads. Si elles conviennent aux applications bâties sur des microservices, elles sont moins adaptées aux applications monolithiques – à moins d’y appliquer une refonte en profondeur.
Il faut également savoir que les économies de coûts ne pourront pas être réalisées si l’on applique une mécanique Serverless à des processus sur le long terme. Ces workloads nécessitent plutôt une infrastructure plus classique.
Les applications ou les API qui nécessitent d’avoir à jongler entre plusieurs plateformes Cloud ne sont également pas adaptées à ces infrastructures. La cause : la verrou-vendeur. Chaque plateforme Serverless dispose de ces propres caractéristiques. Toute migration d’une plateforme vers une autre est difficile et chronophage.
Enfin, pour certaines applications nécessitant des performances élevées, le Serverless impliquera quelques ajustements. Pour exécuter sa première requête à une fonction, une application Serverless a besoin de temps. Ces requêtes peuvent être lentes puisque le fournisseur doit allouer les bonnes ressources pour supporter cette fonction. Les applications qui, en plus, nécessitent un niveau élevé de fiabilité, doivent s’accommoder de cette contrainte à la main en conservant la fonction dans un mode actif.
