kentoh - Fotolia

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 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 rationnaliser 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 rationnaliser encore plus les endpoints. Résultat, le coût de l’infrastructure se retrouve lui-aussi abaissé, car chaque fonction Serverless fonctionnent à 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 rationnaliser 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.

Dernière mise à jour de cet article : janvier 2018

Approfondir

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

En soumettant ces informations à LeMagIT.fr, vous acceptez de recevoir des emails de TechTarget et ses partenaires. Si vous résidez hors des Etats-Unis, vous consentez à ce que vos données personnelles soient transférées et traitées aux Etats-Unis. Politique de confidentialité

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close