Quels sont les réels atouts du Serverless  ?

Frédéric Barthelet, Responsable de l’unité Serverless chez Theodo et membre de l’équipe d’organisation des Serverless Days Paris, partage son expertise sur le sujet.

Le serverless, un ensemble de services spécialisés facturés à l’utilisation

Une infrastructure classique se compose traditionnellement d’un ensemble de serveurs ou machines virtuelles louées pour une période de temps moyennant un coût récurrent fixe, quelle que soit la charge des serveurs.

L’offre serverless des cloud providers tels qu’AWS, Azure ou Google Cloud vient casser ce modèle d’infrastructure, en proposant un ensemble de services spécialisés, managés, visant à remplacer les fonctions les plus courantes d’un serveur web, et facturés à l’usage. L’infrastructure sous-jacente et sa maintenance (mise à jour et de runtime pour patcher les vulnérabilités, gestion de l’espace disque disponible, sécurisation des accès) devient ainsi l’entière responsabilité du fournisseur de serveur.

Utilisation de l’application (bleu)

Coût de l’infrastructure (rouge)

Ces services se scindent en 2 grandes catégories :

• les services FaaS, ou Fonction as a Service, responsables d’exécuter du code métier propre au business de l’application, en réponse à des évènements spécifiques (requête HTTP, fichier uploadé, utilisateur authentifié…)
• les services BaaS, ou Backend as a Service, responsables de réaliser des tâches spécifiques habituellement portées par des fonctionnalités de framework, comme le routing, l’authentification ou le stockage de fichier et qui peuvent servir d’événements déclenchant pour les FaaS.

Fonctionnant de concert pour réduire la code base

Designer une architecture serverless, c’est combiner les bons services au bon moment et les faire intéragir pour construire une application complète en écrivant seulement les lignes de code relatives à son métier, celles qui apportent le plus de valeur. Plus de code pour gérer le routing, le cache, la validation, la gestion d’erreur, l’authentification… On déporte la responsabilité du développeur d’implémenter ces fonctions supports (sans erreur) à un ensemble de services dédiés, spécialisés, maintenus et scalables.

Chez un cloud provider comme AWS, on utilisera par exemple CloudFront pour porter les certificats HTTPS d’une application web, et gérer le cache. Ce dernier sera configuré pour transférer les requêtes HTTP faites à CloudFront vers API Gateway, services de routing, de validation et d’autorisation si utilisé conjointement avec Cognito. Enfin, une Lambda contenant la logique métier propre à l’application sera invoquée par API Gateway, elle-même se reposant par exemple sur DynamoDB comme base de données.