Introduction

Il y a quelques années, le monde de l'informatique a découvert la conteneurisation (Docker, Kubernetes,Chef ...) et de manière générale le mouvement DevOps, visant à aligner le système d'information sur les besoins de l'entreprise. S'accompagne à ces changements l'émergence de nouveaux types d'architectures. C'est ainsi que les architectures Microservices sont nées, et que les architectures dites Serverless sont en train de pointer le bout de leur nez.

Buzzword de l'année 2017, nous allons voir ensemble qu'est ce qui ce cache derrière ce terme, qui sont les grands acteurs actuels et quels sont les avantages et inconvénients de ce type d'architecture.

Serverless, kesako ?

Les architectures Serverless, traduisons sans serveur, correspondent à des applications qui dépendent grandement de services tiers (Baskend as a Service) ou sur des conteneurs sans état pouvant être mis à l'échelle de manière transparente (Function as a Service).

L'objectif premier de ce paradigme d'architecture est de réduire au maximum la compléxité (humaine et matériel) pour ainsi ne payer que ce qui est réellement consommé en puissance de calcul, stockage et bande passante. Ce nouveau mode de facturation a un petit nom : le pay as you go.

Le mot Serverless peut porter à confusion, car derrière tout cela, il y a tout de même des serveurs et du matériel pour faire fonctionner nos belles applications! Il faut comprendre en fait qu'une entreprise qui met en place une architecture Serverless externalise ses processus et son matériel chez un fournisseur pour se focaliser complétement sur les aspects métiers de ses applications.

On ne peut donc pas qualifier de Serverless des infrastructions PaaS comme Heroku car la mise à l'échelle n'est pas transparente sur ce type d'architecture.

Attention aussi, ce n'est pas la solution à tout les cas d'usage! La première étape dans la construction d'un projet est de bien identifier les cas métier, et de ceux-ci en découlent l'infrastructure à mettre en place. Et non pas l'inverse!

Qui pèse dans le game ?

A l'heure actuelle, et comme on peut s'en douter, les principaux fournisseurs de ces services BaaS sont les grands acteurs du Cloud, à savoir Amazon Web Services (le précurseur), Google Cloud Platform et Microsoft Azure. Mais d'autres solutions tentent d'émerger dans cette écosystème (comme Iron.io qui offre une solution FaaS open source et fonctionnant chez n'importe quel fournisseur Cloud).

Ci-après un tableau comparatif des principaux composants BaaS de nos amis les fournisseurs 'ricains.

	Amazon Web Services	Google Cloud Platform	Microsoft Azure Services
Hot Storage	Amazon S3	Google Cloud Storage Standard	Azure Block Storage
Cold Storage	Amazon Glacier	Google Cloud Storage Nearline	Azure Cool Block Storage
Compute (FaaS)	AWS Lambda	Google Cloud Functions	Azure Functions
Database	Amazon DynamoDB	Google Cloud Datastore / Google Cloud Bigtable	Azure DocumentDB

En encore pleins d'autres...

Des avantages...

Commençons par parler des promesses des architectures Serverless.

Séparation des pouvoirs : Un objectif de ce modèle est d'augmenter la productivité des développeurs. Avec cette approche, théoriquement, le développeur peut entièrement se concentrer sur le besoin spécifique qu'il doit réaliser, le code source étant compartimenté et divisé en fonctions autonomes.
Time To Production/Market : Le modèle des architectures Serverless permet de diminuer radicalement le nombre d'étapes incluant la conception, le test et le déploiement du code, avec pour objectif de passer d'un projet de stade d'idée au stade production en quelques jours.
Baisse des coûts de mise à l'échelle : La mise à l'échelle horizontale offerte par les FaaS est automatique et transparente. Elle est gérer totalement par le fournisseur et permet une facturation au plus prés de la charge consommée par le client (temps de calcul). Selon les cas d'usages et de l'état de maturité du projet, cela peut résulter dans des économies non négligeables.
Repensons les process... en les optimisant : Dans le cas des Functions as a Service, la facturation se base sur le temps d'éxécution. Par exemple, si un traitement de 2 secondes n'en prend plus qu'1 après optimisation, alors on observera une réduction de 50% de notre facture. On se doute alors que l'optimisation du code source, qui a peu à peu était abandonné au fil du temps avec les ressources serveurs quasi-illimités, va revenir au centre des débats. Faites chauffer les cerveaux !
Baisse des coûts opérationnels : L'architecture Serverless est by-design simple et externalisée. Les services étant mutualisées avec d'autres, au travers du fournisseurs Cloud qui administre les serveurs, il sera possible de réduire les coûts d'infrastructure et d'opérations/développement. La différence du gain avec une architecture PaaS ou IaaS (Infrastructure as a Service) reste peu significative sur cet aspect là.

...mais quelques inconvenients

Contraintes d'éxécution : Certaines limites d'utilisations sont rencontrées, voir imposées en fonction des fournisseurs. Par exemple, la durée d'éxécution des fonctions est limitée (9 minutes pour Google Cloud, 5 minutes pour AWS). On pourrait se dire que cela traduit le caractère jeune de ce type d'architecture, mais ces limitations sont en place depuis un moment (fin 2016!) et n'ont pas été revue à la hausse depuis. Ca risque pas trop de bouger hélas... Cela peut empêcher leur utilisation dans certains cas comme le traitement vidéo par exemple.
Dépendances fortes auprès des fournisseurs Cloud : Malgré l'apparition de framework comme Serverless.io pour bousculer l'ordre établi, aucune spécification ou norme n'éxiste encore aujourd'hui pour aboutir à un language commun. Cela oblige le client, après définition de ses cas d'usage, d'identifier et de choisir un unique fournisseur pour l'ensemble des services qu'il souhaite utiliser, afin de profiter des avantages offerts par les architectures Serverless cités plus haut.
Le code non testé peut coûter cher : Comme la facturation se fait au temps de calcul ou au nombre d'invocation des fonctions, dans le cas où une fonction peut être utilisé au travers d'une API par une autre personne/société, il est important de pouvoir s'assurer au travers de tests et procédures qu'aucun usage abusif ne peut être fait.

En résumé...

Les architectures Serverless proposent une approche s'appuyant notamment sur des services "clés en main" pour fournir une abstration de la partie gestion de l'infrastructure. Elle se veut plus simple et promet une réduction des coûts aussi bien d'infrastructure qu'opérationnels. Toutefois cette technologie est encore jeune et il lui faudra encore un peu de temps pour être mis en place dans les entreprises qui peinent déjà pour un grand nombre à suivre le virage du Cloud et de la containeurisation.

Pour aller plus loin, je vous recommande l'article de Mike Roberts qui explique très bien, et en détail cette notion d'architecture Serverless.