L’architecture serverless (ou informatique sans serveur), bien que n’étant pas une techno nouvelle, connait un succès toujours grandissant. Que ça soit via AWS, Microsoft ou Google Cloud, de plus en plus de projets ont leur back-end (ou une partie) externalisé sur ces services cloud.
Vous ne savez pas exactement ce qu’est le serverless ? Vous hésitez à l’utiliser pour votre prochain projet ? Faisons le point dans cet article.
L’architecture serverless, en détails
Le serverless, la définition
L’architecture serverless est donc un paradigme de cloud computing dans lequel toute ou une partie de l’exécution back-end est déléguée à des fournisseurs. L’architecture serverless n’est donc pas sans serveur ; ce dernier est simplement géré par le fournisseur de services cloud.
Cela veut dire que le code source écrit pour le back end (ainsi que toute la configuration dudit serveur) est stocké et exécuté par ce prestataire, et non plus en interne (ou du moins géré en interne).
Il existe deux types d’offres serverless : BaaS (Backend-as-a-Service) et FaaS (Function-as-a-Service). Voyons-les en détails.
Backend-as-a-Service (Baas)
Une architecture serverless de type Baas met à disposition une multitude de fonctionnalités et d’applications tiers, notamment :
- Un service d’authentification avec chiffrement ;
- La gestion de base de données ;
- L’envoi de notifications (Push), d’emails.
C’est donc une grosse partie du back qu’on configure et qu’on ne code pas. Le modèle Baas permet vraiment de se concentrer sur le développement front-end et/ou de gagner un temps important en développement.
Function-as-a-Service (Faas)
Le modèle Faas a lui un fonctionnement différent : le fournisseur cloud nous met à disposition des fonctions, contenant du code spécifique faisant des actions définies.
Ce code, ou ces services, peuvent être appelés par différents évènements ou triggers. Par exemple :
- Une requête HTTP ;
- Un téléchargement de fichier ;
- Un évènement planifié (une tâche cron) ;
- Des évènements de base de données.
Une fois l’action terminée, ou le morceau de code exécuté, le service repasse en mode veille et attend le prochain trigger.
Le modèle Faas requière lui plus de ressources en développement, mais permet de garder la main sur les actions de son back tout en profitant des avantages du serverless.
Serverless : les raisons de l’utiliser
Tout cela semble bien beau, d’avoir un back-end facile à configurer chez un prestataire, mais quels en sont les avantages, exactement ?
Un coût réduit
L’utilisation du serverless peut réduire considérablement les coûts d’un projet, et ce à plusieurs niveaux.
Déjà, contrairement à une gestion interne ou via un hébergeur classique, le backend serverless n’est facturé que lorsqu’il est utilisé. Par exemple en cas de Faas, on ne paye que lorsque la fonction est exécutée. Une fois retournée dans son état de veille, elle ne coûte plus rien.
Aussi, on économise sur les coûts de développement. L’utilisation d’un serverless Baas peut permettre de supprimer toute la chaine d’authentification d’un utilisateur (enregistrement, récupération de mot de passe, droits), entre autres.
En plus de ça, on évite évidemment les coûts de mise en place et d’entretien des serveurs (mises à jour de sécurité, etc.), qui sont automatiques et gérées par le prestataire cloud.
Un développement plus rapide
Si on délègue une grosse partir du développement de la partie back, ne serait-ce que pour la création d’un serveur avec des règles de sécurité, c’est du temps gagné pour développer autre chose.
C’est idéal si on veut se concentrer sur le front-end ou sur le développement de nouvelles fonctionnalités.
On peut même envisager de n’avoir qu’un seul développeur full-stack avec une orientation front-end, plutôt que deux développeurs à temps plein.
Plus écologique
À l’heure où l’on parle de plus en plus d’éco-conception dans l’informatique et le développement, utiliser des serveurs qui ne s’activent que lorsqu’on a besoin d’eux va évidemment dans le bon sens.
Les inconvénients du serverless
Si le serverless présente des avantages certains, ce mode de fonctionnement comporte aussi des inconvénients.
Des tests difficiles
Quand on n’a plus entièrement la main sur notre code et son environnement d’exécution, le tester devient beaucoup plus difficile.
C’est le cas avec le modèle Faas, où le code est découpé en fonctions (ou services), exécutées séparément sur un serveur distant. Dans ce cas, il n’y a pas trop de problème a faire du test unitaire, mais qu’en est-il des tests d’intégration ?
Les performances
Les performances du serverless sont très bonnes, sauf lorsque le service se met en “veille”. Même si c’est le principe du serverless (plus particulièrement du Faas) – on ne paye que lorsque le service est actif – la sortie de l’état de veille peut mettre un certain temps. De quelques centaines de milli-secondes à plusieurs secondes, parfois.
Cette latence peut conduire à une perte de performances. Heureusement, la fonction ne se met pas instantanément en veille après sa fin d’exécution, cette perte reste donc relative.
La dépendance au fournisseur cloud
Que l’on choisisse AWS Lambda d’Amazon ou Google Cloud Functions, on créé une dépendance entre notre projet et le fournisseur. C’est-à-dire que notre code doit être conforme aux spécifications requises, et donc changer de fournisseur, si le besoin s’en fait sentir, aura un coût.
On doit accepter la politique du fournisseur cloud
Lorsqu’on passe par un fournisseur serverless, on accepte de fait sa politique. Il héberge notre code, voire nos bases de données, et nous en dépossède en quelque sorte. Si jamais les conditions viennent à changer, soit chez le fournisseur, soit parce qu’il est soumis à de nouvelles règles, on n’aura pas le choix que de les accepter – où de s’en aller.
Cela est d’autant plus important que les trois plus gros fournisseurs de cloud computing sont américains : Amazon, Google et Microsoft. Ils sont donc soumis aux mêmes lois du même pays.
Les cas d’utilisation du serverless
On a vu les avantages et les inconvénients d’utiliser ce type de techno pour faire du back-end, mais quand, exactement, est-il judicieux de faire du serverless ?
Voyons ensemble les principaux cas d’utilisation du cloud computing sans serveur.
Le serverless, et notamment le modèle Function-as-a-Service, est parfaitement adapté aux fonctions simples et répétitives. Typiquement, un ensemble d’actions simples, effectuées via quelques fonctions contenant quelques lignes de code, ne nécessite pas l’utilisation d’un serveur complet. Ici, utiliser un service externe comme AWS est parfaitement adéquat.
L’utilisation type de cet ensemble d’actions simples, c’est le traitement des données et des actions effectuées via des objets connectés (Internet of Things). Ces actions sont répétitives et ne nécessitent pas beaucoup de puissance de traitement.
C’est également le cas du traitement de fichiers (PDF, etc.) et de l’OCR (optical character recognition – Reconnaissance optique de caractères).
Les fournisseurs de cloud serverless
On les a déjà cités, mais parlons en un peu plus : il existe trois principaux services serverless : AWS Lambda, Google Cloud Functions (avec Firebase) et Microsoft Azure. Il en existe d’autres, avec par exemple IBM, mais ils sont tout de même moins utilisés.
AWS Lambda est un service serverless faisant partie de la suite AWS (Amazon Web Services). Introduit en 2014, la plateforme supporte un multitude de technos back-end : Node.js, Python, Java, Go, Ruby et C#. AWS Lambda compte une version gratuite, puis devient payante au-delà d’une certaine utilisation : 1 million de requêtes et 400 000 Go-seconde de temps de calcul par mois dans la version gratuite. 1 Go-seconde correspondant à 1 seconde d’exécution avec 1 Go de mémoire provisionnée.
En face de Lambda, on retrouve Google Cloud Functions. Ce service fait lui aussi partie d’une suite de services cloud, de Google. Elle supporte du code en Node.js, Java, Python, ou Go. Le service de Google Cloud Functions est moins cher qu’AWS Lambda, et sa version gratuite est plus intéressante (2 millions d’appels gratuits par mois).
Enfin, le troisième principal fournisseur de service cloud est Microsoft Azure. Azure contient des dizaines d’outils cloud. Celui permettant notamment de faire du Faas est Azure Functions, qui peut être utilisé avec les technos .NET (évidemment), Node.js ou Java. Son plan gratuit est le même qu’Amazon Web Services, avec 1 million de requêtes et 400 000 Go-seconde par mois.
Le serverless, l’avenir du back-end ?
Alors, le serverless va-t-il prendre le dessus sur le développement backend “classique” ? Non, évidemment ! Cela fait des années que le serverless s’est démocratisé, et s’il avait dû remplacer le back-end, il l’aurait déjà fait.
Il est néanmoins vrai que les technos serverless, notamment via AWS, sont de plus en plus utilisées. Grâce aux avantages qu’elles donnent, notamment un développement plus rapide et plus simple, on ne peut que comprendre cet engouement.
Toutefois, il y a des besoins trop spécifiques pour pouvoir utiliser un service cloud dans 100% des cas d’utilisation, et le fait qu’une entreprise tierce ait la main sur notre back est aussi à prendre en considération avant de sauter sur cette techno.
Et vous, que pensez-vous du serverless ? Donnez-nous votre avis en commentaire !
