Serverless

Une fois de plus, un buzz word bien à la mode ces temps-ci dans le monde de l’informatique, SimplX vient donc vous aider à démystifier tout cela et vous expliquer ce qui se cache vraiment derrière cet anglicisme barbare… Pour les plus aguerris à la langue de Shakespeare, vous vous dites simplement que Serverless = Sans serveur, et bien nous allons découvrir ensemble que ce n’est pas tout à fait le cas.

Qu’est ce que Serverless ?

Vous êtes normalement familier avec l’architecture traditionnelle client/serveur, les architectures à 2 niveaux ou à trois niveaux (2+1 tiers pour les données), aujourd’hui, presque toutes les applications métiers ont un ou plusieurs front-end, connectés à un ou plusieurs back-end chargés de fournir les services. Avec l’émergence des conteneurs, du DevOps et des fournisseurs de services cloud (Amazon Aws, Google Cloud, IBM BlueMix) de nouvelles techniques ont vu le jour. Vous avez certainement entendu parler d’API WS ou RESTfull et surtout d’architecture micro-services, des services simples, scalables horizontalement, réduits à une fonctionnalité métier et conçus pour être stateless (ne garde pas d’état entre deux exécutions). Le développement back-end, orienté service, et stateless a ouvert la voie à l’architecture serverless. En effet, entre deux appels à votre service, puisqu’il n’y a aucune persistance de données, vous n’avez pas besoin que votre service soit actif, et consomme des ressources inutilement, si le service pouvait être fourni « on-demand », cela serait transparent pour tout le monde et n’affecterait pas la fourniture du service. Et c’est exactement ça qui est proposé par le serverless : on déploie son service chez un fournisseur de cloud, on lui définit des triggers (événements déclencheurs) pour son exécution, et celui-ci gère pour vous la disponibilité sur demande de ce service (déploiement, installation, exécution). On parle alors de FaaS, « function as a service », et l’implémentation la plus populaire est sans aucun doute celle d’Amazon AWS, Lambda.

Serverless  ≠ Sans serveur

Serverless n’est donc pas tout à fait sans serveur, au sens stricte du terme. Car il faut évidemment des serveurs physiques pour faire tourner et exécuter les services à l’instant T, c’est simplement que ce n’est plus vous qui les gérez, cela est sous-traité au fournisseur de cloud. Et on parle aussi de sans serveur, car le service n’est pas tout le temps provisionné sur un serveur, il l’est uniquement pour son exécution, et si il n’est sollicité qu’une fois par mois alors le reste du temps il est effectivement sans serveur. Vous n’avez plus besoin d’allouer des ressources en continu, ou pire, avoir un administrateur système qui s’occupe de lancer / terminer le service sur demande, les fournisseurs de cloud s’occupent de tout, et vous ne payez qu’à l’exécution !

Les avantages d’une architecture Serverless

Le coût !

Comme nous l’avons vu, le premier principe du Serverless c’est l’externalisation. Celle-ci permet la réduction de deux coûts : le coût d’infrastructure (vous ne payez plus qu’à la consommation de vos services, l’infrastructure est mutualisée) et le coût des employés DevOps.

Le coût de développement se trouve lui aussi réduit, l’architecture nous poussant à utiliser des services tiers pour réaliser des fonctions standards comme l’authentification, la sécurité. Moins de développement et pas de coût de maintenance pour ces aspects applicatifs.

La scalabilité

L’avantage le plus important selon moi, et en particulier lorsqu’on vient de lancer un service avec peu de certitude sur le trafic et le dimensionnement, c’est l’élasticité du service. Elle est ici gérée par le fournisseur, quelle que soit sa complexité, avec la mise à l’échelle horizontale ou verticale automatique, vous paierez exactement ce dont vous avez besoin et vous aurez la garantie d’avoir un service toujours disponible!  Selon vos besoins et vos « use cases » cela peut engendrer des économies énormes (je reprends l’exemple d’une fonction utilisée occasionnellement, comme le redimensionnement d’une photo par exemple).

L’optimisation

Etant donné que l’on passe ici dans un modèle de paiement à l’exécution et aux ressources consommées, il y a tout intérêt à optimiser le développement des services. En plus de diminuer le temps de réponse pour votre applicatif et/ou vos clients, vous diminuerez votre facture d’hébergement. Tout le monde y gagne !

Les inconvénients

Et oui, comme pour toute chose qui brille un peu trop, il y a toujours l’envers du décors! Et il existe bien sur des cas d’utilisation où le serverless est à proscrire.

La dépendance.

Une fois que vous avez choisi votre fournisseur de service, vous êtes totalement dépendant de celui-ci. Aucune spécification n’existe aujourd’hui pour l’adoption d’un langage commun entre les fournisseurs, même si certains frameworks comme serverless.io essaient de bypasser ces frontières, une fois votre fournisseur choisi vous devrez garder ce choix pour garantir une communication entre les services. (Exemple : API Gateway déclencheur de AWS Lambda, impossible ou très compliqué et difficilement maintenable de définir un trigger d’AWS Lambda ne provenant pas d’AWS).

Exécution.

Latence

Votre service FaaS n’étant évidemment pas toujours actif lors de son exécution (et ce pour le plus grand plaisir de votre porte monnaie), il faut compter avec une certaine latence au démarrage dans certains cas. Cela peut aller jusqu’à plusieurs secondes pour des services java non provisionnés qui requierent l’utilisation d’une JVM. Chez SimplX nous développons toutes nos apps avec la stack javascript, un langage optimisé pour les FaaS, mais si ce n’est pas le cas chez vous, il faut bien se poser la question de vos besoins en performance avant de migrer vers une archi serverless.

Durée

Le fournisseur limite malheureusement la durée d’exécution de vos FaaS, elle est actuellement de 5 min max pour Amazon AWS. Si vous avez des gros traitements batch de fichier, ou de la manipulation de vidéo, vous pouvez oublier serverless pour ce type de service.

Conclusion

Vous avez maintenant les clefs en main pour vous posez les bonnes questions, et entrevoir si le serverless est ou non fait pour vous. Si vos cas d’utilisation le permettent, alors la facturation à la demande, la mise à l’échelle et la gestion automatique et transparente de l’infrastructure peuvent rapidement vous apporter des bénéfices (financiers mais pas seulement). Et n’oublions pas que c’est une technologie encore récente (3/4 ans max), elle rencontre une forte adoption et va forcément gagner en maturité et en efficacité, il convient donc de suivre son évolution. Un cas d’utilisation qui vous est déconseillé aujourd’hui peut trouver son adaptation serverless demain…