Serverless : Le guide complet

Le marché du serverless a une croissance de plus de 30% par an et sa popularité grandissante attire la curiosité des développeurs mais aussi des décideurs.

Mais ce n'est pas un remède miracle et il est essentiel de bien comprendre le serverless pour savoir si c'est la bonne solution pour un nouveau projet ou pas.

Ce guide vous permettra de tout comprendre sur ce nouveau pendant de l'hébergement :

• Qu'est-ce que le serverless.
• Pourquoi le serverless croît en popularité.
• Avantages et inconvénients du serverless.
• Dans quels cas le serverless est-il recommandé.
• Et comment Scalingo répond à ces problématiques.

Enfin à la fin de l'article, on vous expliquera comment faire du serverless sur Scalingo.

Vous êtes prêt ? On vous explique tout sur le serverless !

Serverless, c'est quoi ?

Le serverless fait référence à un environnement applicatif managé. Si on traduit le terme littéralement depuis l'anglais, le terme Serverless signifie "Sans serveur".

Cependant et malgré son nom, il y a bien des serveurs mais sa gestion est totalement abstraite.

Contrairement à des formes d'hébergement classiques (serveurs dédiés, VPS, IaaS), le serverless ne requiert pas des utilisateurs une maintenance du système d'exploitation ou des logiciels installés sur les serveurs.

C'est le fournisseur du service qui s'occupe de tout : configuration des serveurs, déploiement, monitoring, logging, alertes, etc.

De ce fait, un développeur n'a besoin que d'écrire le code de son application et rien de plus.

PaaS vs FaaS vs Kubernetes

Avant d'entrer dans le vif du sujet, il nous a semblé important d'apporter quelques précisions aux différences entre différents termes utilisés fréquemment lorsqu'on aborde le concept de serverless.

En effet, beaucoup d'articles et de projets font un amalgame entre les termes serverless et FaaS (Function-as-a-Service) alors que des sociétés comme Google et nous-même (Scalingo) utilisons un cadre plus large du serverless.

Par conséquent voici comment nous utilisons le terme serverless pour les services suivants :

• Platform-as-a-Service, ou PaaS, est donc un environnement applicatif managé.
• Le Function-as-a-Service, ou FaaS, dont la différence principale avec le PaaS se trouve dans le fait que les serveurs sont permanents pour le PaaS et éphémères pour le FaaS.
• Et le Backend-as-a-Service, ou BaaS, qui réfère à des services prêt-à-l'emploi accessibles par des APIs.

Ce guide se concentrera particulièrement sur les différences entre le PaaS et le FaaS.

Kubernetes et serverless ?

Kubernetes est un système d'orchestration permettant aussi d'alléger le travail des développeurs et administrateurs système.

Cet outil permet d'automatiser le déploiement et la montée en charge, mais contrairement à du serverless de nombreuses choses sont encore à gérer manuellement comme le logging, le monitoring, les alertes, etc.

Kubernetes peut néanmoins être utilisé comme base pour un PaaS ou un FaaS. C'est possible par exemple avec des projets open-source comme OpenFaaS et Kubeless.

Pourquoi en est-on arrivé au Serverless ?

Depuis le début des applications pour le web, leur architecture est parfois très simple : tout le code se trouve au même endroit. On parle alors essentiellement d'applications monolithes. Cependant, il existe bien des cas où la réalité est différente.

Les challenges de la montée en charge

Mais avec la popularité grandissante du web, il est devenu difficile d'utiliser ce genre d'architecture pour monter en charge et gérer des millions de requêtes par seconde.

Deux stratégies de montée en charge existent mais aucune n'est parfaite :

• Le scaling vertical consiste à remplacer les serveurs existants par des serveurs plus performants. C'est une stratégie généralement utilisée quand un projet n'a qu'un ou deux serveurs et se révèle coûteux, difficile et avec une possible indisponibilité de vos applications.
• Le scaling horizontal consiste à gérer de nombreux serveurs, souvent plus petits qu'avec une stratégie verticale. Mais gérer l'ajout et le retrait des serveurs ainsi que l'architecture de l'infrastructure peut vite devenir un casse-tête.

De plus, la montée en charge n'est pas le seul challenge auxquels font face les administrateurs systèmes. Le DevOps est un autre challenge sur lequel il faut se pencher.

Les challenges du DevOps

DevOps est un terme utilisé pour désigner l'unification des processus de développement et d'exploitation des applications.

Ces dernières années, le DevOps est devenu un avantage compétitif pour innover.

Avec une meilleure collaboration entre les développeurs et l'opérationnel, une meilleure automatisation et une plus grande transparence sont possibles. Il en découle une plus grande rapidité pour le livraison des projets tout en gagnant en stabilité.

Hélas, la maintenance requiert du temps et surtout une grande expertise que ce soit sur le système de builds, les environnements de développement, test et production, et enfin sur la correction des problèmes de déploiement.

La solution : serverless

L'évolution du web a permis la création de nombreux outils pour faire face aux problèmes grandissants d'une plateforme en pleine croissance avec des milliards d'utilisateurs quotidiens aux quatres coins de monde.

Parmi ces outils on trouve notamment les PaaS et les FaaS que nous vous citions plus haut.

Le serverless permet d'avoir l'esprit tranquille sur toute la chaîne de valeur du web : déploiement, montée en charge, delivery, etc.

Comme nous vous le disions plus haut, avec le serverless c'est le fournisseur du service qui s'occupe de tout : configuration des serveurs, déploiement, monitoring, logging, alertes...

Les avantages du serverless

Les changements dans la manière de développer des applications et de les héberger a donc créé de nouveaux problèmes et le serverless est une des solutions qui a permis de corriger ces problèmes et alléger le travail des développeurs et administrateurs système.

Le serverless a de nombreux avantages par rapport à de l'hébergement sur des serveurs dédiés ou des VPS.

Néanmoins, une grande partie de ces avantages se trouvent déjà dans le Platform as a Service.

Les avantages du serverless

Le serverless a de nombreux avantages par rapport à de l'hébergement sur des serveurs dédiés ou des VPS.

Pour en savoir plus sur les avantages et inconvénients spécifiques du PaaS, nous avons un guide complet sur le sujet.

Avantages partagés entre le PaaS et le FaaS

Pas d'infrastructure à maintenir

L'avantage principal du serverless et du PaaS c'est que la configuration et la maintenance de l'infrastructure n'est plus qu'un mauvais souvenir !

Fini les problèmes de sécurité de l'infrastructure, votre hébergeur s'occupe de tout pour vous.

Une montée de version qui se passe mal ? Plus jamais.

Quand l'opérationnel n'a plus besoin de passer son temps à gérer l'infrastructure, elle peut passer son temps à simplifier les procédures de DevOps améliorant la productivité de tout le monde.

Facilité de déploiement

Le déploiement demande plus de maintenance que ce qui est raisonnable.

De nombreux scripts et procédures à maintenir et des bugs à chaque fois qu'une nouvelle dépendance est ajouté à une application.

Avec le serverless et le PaaS, plus de soucis !

Juste une ligne de commande et c'est terminé. Et Scalingo offre aussi une intégration avec GitHub et GitLab permettant de déployer automatiquement sans même une commande.

Un projet complexe demandera un peu plus de configuration que ça, mais c'est en général un plus mince travail qu'auparavant.

Avantages exclusifs au FaaS

Scaling automatique

Le succès de votre application va créer des problèmes de scalabilité.

Si les performances ne sont pas au rendez-vous, cela se traduira par moins de clients, une satisfaction en berne et une confiance amoindrie.

La viralité d'une campagne marketing peut très rapidement créer des piques de trafic temporaires qu'il faut pouvoir gérer.

De même avec les périodes d'achat dans l'e-commerce comme le Black Friday.

Le serverless n'a pas ces problèmes. Plus besoin de se préoccuper d'avoir le bon nombre de serveurs au bon moment.

La montée en charge se fait automatiquement sans que personne n'aie besoin d'intervenir.

Et comme chaque partie de votre application peut monter en charge indépendamment de l'autre, c'est aussi une économie d'argent. Au lieu d'avoir un serveur pouvant gérer toute l'application et tous les potentiels piques de trafic.

Néanmoins, certains PaaS offrent une fonctionnalité pour faire du scaling automatique. Nous verrons plus tard comment le faire avec Scalingo.

Paiement à la consommation

Enfin le dernier avantage du serverless est le paiement à la consommation.

Plus besoin de payer tout le mois pour un serveur alors que vous n'avez de l'activité seulement à certaines heures.

Ne pas payer la nuit quand personne n'utilise l'application, un rêve devenu réalité avec le serverless.

Un avantage secondaire à celui-ci est la réduction de la consommation en ressources.

La demande en électricité des technologies de l'information pourrait représenter 20% de la demande totale en 2030. Moins d'électricité utilisé est un enjeu crucial pour l'avenir de la planète.

Mais le serverless est plus cher à la minute que les alternatives comme le PaaS. Si l'application est active de manière constante, le serverless ne sera pas avantageux.

Mais les usages idéaux du serverless sont aussi couverts par certains PaaS. Avec Scalingo, vous pouvez exécuter des conteneurs de manière occasionnelle que vous ne payez aussi seulement qu'à la consommation. Nous reviendrons plus en détails plus tard dans l'article.

Inconvénients du FaaS (et comment Scalingo y répond)

La solution parfaite n'existe pas et le FaaS n'a donc pas que des avantages.

Latence

Le paiement à la consommation a la conséquence suivante : les serveurs ne sont pas toujours actifs et il faut donc les démarrer.

Du coup, il y a un temps de latence entre une requête et sa réponse quand les serveurs sont inactifs.

Les solutions techniques utilisées pour le FaaS sont optimisées pour réduire cette latence au minimum mais ça reste tout de même non négligeable.

Cela dépend aussi du langage de programmation que vous utilisez. Certains ont un temps de démarrage qui sera beaucoup plus important que d'autres.

Donc dans des cas d'usages où le temps de réponse est critique, le FaaS n'est pas du tout adapté.

Avec le PaaS, les serveurs sont toujours actifs et permanents, ces problèmes de latences n'existent donc pas.

Limitations techniques

Les plateformes FaaS existantes ne sont encore pas aussi matures que les PaaS et les autres alternatives.

Premièrement, peu de langages sont supportés. Par exemple, AWS Lambda ne supporte officiellement que Java, Go, PowerShell, Node.js, C#, Python et Ruby.

Une API existe pour le support d'autres langages par la communauté mais ces supports ne seront pas aussi stables que les langages officiellement supportés.

Un autre problème du FaaS vient de la connexion avec la base de données. Avec les microservices et le FaaS, le nombre de connexions aux bases de données augmente considérablement et il faut donc des hébergeurs supportant ce type d'usage.

Une solution est la base de données FaaS. Comme pour les applications, vous ne payez qu'à la consommation et ces bases de données sont faites pour ne pas être limitées par un certain nombre de connexions.

Mais peu existent actuellement et elles requièrent des librairies spécifiques pour être utilisé avec votre langage préféré, librairies qui n'existent pas toujours, ajoutant encore une limitation de plus.

Enfin le FaaS a aussi des limites de mémoire et de CPU. Si un de vos workflows est intensif sur ces fronts, cela posera problème.

Au contraire avec un PaaS comme Scalingo, vous avez un support de plus de 30 langages, et des bases de données MySQL, PostgreSQL, Redis, MongoDB, Elsticsearch et InfluxDB.

Eco-système réduit

Il y a aussi peu de ressources et d'outils pour apprendre à utiliser un FaaS et à être plus productif comparé aux modèles d'architecture d'applications plus classiques.

De ce fait, du temps sera perdu sur le développement par rapport au temps gagné sur l'opérationnel.

C'est un sacrifice dont il faut être conscient quand on fait le choix du FaaS.

Vendor lock-in

Le FaaS a aussi des implémentations et des fonctionnalités différentes chez chaque hébergeur.

Il est donc impossible de migrer de l'un à l'autre sans changer le code de l'application.

Si l'hébergeur que vous avez choisi disparaît, supprime des fonctionnalités ou encore augmente les tarifs, cela va créer plus de problèmes que ce que le FaaS vous en aura fait gagner.

Ce qui n'est pas le cas des alternatives.

Avec Scalingo, il y a une compatibilité avec Heroku ce qui vous permet de migrer sans aucun changement de code.

Les cas d'usages convenant au FaaS

Complément à un site statique

Quand vous avez besoin de quelques fonctionnalités sur un site statique, le FaaS est très bien adapté.

Prenons l'exemple d'un formulaire de contact. Si vous avez un site statique, vous allez devoir payer un SaaS pour gérer vos formulaires. Et cela coûte en général dans les 10$ par mois.

Mais avec le FaaS, vous pouvez gérer votre formulaire de contact vous-même pour une fraction de ce coût.

Tâches récurrentes

Toutes les applications ont leur lot de tâches récurrentes : gestion des backups, monitoring, etc.

Des tâches cruciales et qui doivent donc ne pas être dépendantes des possibles problèmes de disponibilité de l'application.

Le FaaS est conseillé dans ce cas-là aussi.

Webhooks

Il est devenu presque inévitable de devoir intégrer son application à des services externes et de ce fait la gestion de webhooks est devenu courante.

Mais la charge que ces webhooks reçoivent est totalement différente du reste de l'application. Certains ne recevront peut-être que quelques requêtes par jour.

De ce fait, utiliser le FaaS pour les héberger est une option sérieuse.

Traitement de données

Si vous avez des besoins sur le traitement des données, le FaaS peut être adapté.

Mais pas dans tous les cas.

En effet, le FaaS n'est pas vraiment fait pour des tâches qui ont besoin de beaucoup de temps pour s'exécuter.

Généralement, les plateformes FaaS ont des limites sur la durée d'exécution donc il faut veiller à en être conscient avant de s'engager dans cette voie.

Background jobs

Enfin le FaaS est utile pour les background jobs.

La génération de PDFs ou d'images, le traitement par lot, l'exécution d'algorithmes et bien d'autres sont des portions d'application qui ont des besoins spécifiques en ressources et le FaaS pourra les faire monter en charge indépendamment.

Comment fonctionne le serverless chez Scalingo ?

En plus du PaaS, Scalingo offre plusieurs fonctionnalités permettant de profiter des avantages normalement exclusifs au FaaS : des conteneurs éphémères et le scaling automatique.

Conteneurs one-off

Pour tous les cas décrit dans la section précédente pour lesquels le SaaS est adapté, il est possible de faire la même chose avec Scalingo et ses conteneurs one-off.

Ces conteneurs ne sont pas toujours actifs contrairement aux conteneurs des applications et peuvent être lancés en ligne de commande ou avec l'API.

Il devient alors très aisé de lancer ces conteneurs de manière récurrentes ou à la suite d'évènements.

De plus, comme les conteneurs one-off sont identiques à ceux de votre application, pas besoin de créer du code spécifique comme avec les services FaaS. Vous pouvez utiliser vos frameworks préférés.

Au final, vous ne paierez qu'à la consommation et vous pourrez faire la montée en charge de votre application de manière bien plus sereine.

Scaling automatique

Comme les plateformes de FaaS, Scalingo permet de faire la montée en charge de vos conteneurs automatiquement.

Vous pouvez gérer le nombre de conteneurs minimum et maximum que doit avoir votre application, quelle métrique utilisait comme indicateur de scalabilité et la cible de cette métrique qui déclenchera la montée en charge.

Etude de cas : Comment Studo utilise Scalingo pour faire du FaaS

Studo, une application qui permet aux étudiants autrichiens de gérer leurs études en ligne, utilise Scalingo depuis plusieurs années et nous les avons interviewés pour en savoir plus sur leur utilisation des conteneurs éphémères.

Retrouvez cette étude de cas dans un article dédié : Comment Studo utilise Scalingo pour faire du FaaS.

Conclusion

Le serverless est donc un environnement applicatif managé incluant des services tels que le PaaS, FaaS et le BaaS.

Chacune de ces solutions a des avantages et des inconvénients qu'il est crucial de prendre en compte au moment du choix de l'hébergement d'un projet web.

Des solutions matures comme Scalingo permettent de minimiser les inconvénients du serverless avec la versatilité du PaaS allié au scaling automatique et aux conteneurs éphémères.