Je tiens à préciser que dans cet article je parle de déploiement d’applications Web et de scripts d’automatisation, pas d’applications client lourdes.

Le serverless

Le serverless est une méthode permettant de déployer des morceaux d’application sans se soucier de l’infrastructure technique porteuse. Dans un déploiement classique (on parle là bien de legacy mais également de déploiements type Docker EE / Kubernetes), notre application est bundlée et doit être déployée sur un ou plusieurs serveurs. Ce processus peut être automatisé et la couche d’infrastructure un peu abstraite (coucou Kubernetes), mais le principe reste le même.

Dans une architecture serverless, l’application est « cassée » en modules, puis en fonctions, un peu comme dans un développement normal, mais encore plus. En effet, il va s’agir de déployer chaque fonction de notre programme individuellement.

Le fonctionnement du serverless est simple :

  1. Une fonction (et ses ressources et dépendances) réside sur un serveur d’exécution
  2. Un événement vient trigger la dite fonction
  3. Cette dernière s’exécute et éventuellement (mais pas forcément) produit un résultat
  4. Le résultat produit est retourné au déclencheur de l’évènement

Cela peut paraître une idée saugrenue, mais une infrastructure serverless apporte énormément d’avantages stratégiques pour le développement et la maintenabilité d’une application :

  • Chaque fonction peut être écrite dans un langage propre, ce qui est un des gros points du serverless. Un projet aux multiples facettes, porteur de backend Javascript, de scripts d’automatisation Java, de scripts de maintenance Shell et d’outils de statistiques Python peut voir toutes ses fonctions réunies dans un seul projet.
  • Chaque fonction peut être trigger par un ou plusieurs types d’événements, permettant de définir une fonction comme appelable par, par exemple, un appel http sur une URL définie, mais également un événement système, un appel RPC, et même, avec des intégrations plus poussées, un message Slack ou Discord, un événement de base de données, etc.
  • Chaque fonction réside dans son propre environnement d’exécution, ce qui permet d’exécuter la même fonction dans plusieurs environnements, mais également de gérer la scalabilité de chaque fonction indépendamment, ce qui veut dire que si une fonction n’est pas utilisée, elle est tout simplement désinstanciée du serveur d’exécution (ce qui peut causer le problème du Cold Start, expliqué plus bas, mais fait qu’une fonction inutilisée ne vous coûte rien).
    En clair, votre équipe n’a plus besoin d’un cluster entier de machines pour déployer son projet, mais juste d’un provider serverless (comme AWS avec lambda), qui facturera simplement à l’utilisation.
  • Votre équipe de développement n’a plus besoin de se soucier d’infrastructure, ce qui est un avantage considérable dans beaucoup de petites structures, mais également dans des grosses structures où les développeurs sont recrutés pour… eh bien développer (ce point a tendance à être négligé, croyez-moi).
  • Le Time To Market est considérablement réduit, car lorsqu’une fonctionnalité est développée est testée, vous avez juste besoin de redéployer la ou les fonctions impactée(s), ce qui se fait généralement en une à deux commandes. La nouvelle version de la fonction est ensuite accessible à la place de l’ancienne, pour tous les triggers définis, pour tout le monde. Facile non ?

Alors avec ça, pourquoi continuer à faire des applications classiques ? Eh bien le serverless, c’est bien, mais comme tout ce qui est bien et novateur, il vient également avec son lot de problématiques :

  • Il est plus compliqué de débugger et tester son application. Il est vrai que l’environnement de production est plus compliqué à reproduire pour le développement qu’avec admettons une image Docker ou un environnement JVM défini. Le fait que l’application soit cassée en plein de petites fonctions peut également être intimidant, mais c’est également un moyen de bien séparer les différentes logiques, donc chacun son avis.
  • Les traitements longs n’ont pas leur place en serverless, de par son architecture, faite pour des processus courts qui se contentent de répondre rapidement à un événement. Les processus longs (quelques secondes à quelques minutes) coûteront cher (car facturés au temps d’exécution) et pire, risqueront de se voir interrompus avant la fin.
  • La portabilité n’est pas toujours assurée, car le serverless ne se repose pas (pas souvent) sur une infrastructure maîtrisée par l’entreprise. Des outils pour réaliser différentes fonctions sont alors mises à disposition par le provider, et ces fonctions lui sont propres, ce qui rend notre compte dépendant du provider.
  • Les performances de l’application peuvent être affectées, car, on le rappelle, chaque fonction tourne dans son propre environnement d’exécution, son propre « conteneur » pour faire un parallèle avec Docker ou k8s, et si une fonction n’est pas du tout utilisée, le provider va la scaller à 0 instances. C’est à la fois le plus gros avantage du serverless (car une fonction non utilisée ne coûte rien), mais son plus gros inconvénient, car si une fonction scallée à 0 est appelée, il lui faut le temps de démarrer. Ce temps est généralement court (quelques secondes tout au plus), mais il faut savoir qu’il existe.
    Pour information, ceci s’appelle sobrement le Cold Start.

 

Soyons clair, aucune de ces problématiques n’est insurmontable. Des moyens existent pour les contourner, et le jeu en vaut la chandelle.

Les outils du serverless

Si le serverless vous intéresse, voici quelques outils, ressources et providers sur lesquelles vous devriez vous pencher :

  • com, framework serverless permettant d’accélérer le développement et d’émuler un environnement serverless (par exemple AWS, Azure, Google, Kubeless, etc.). Ils ont également un blog très complet et très actif qui parle de l’actualité du serverless
  • Knative et Kubeless, deux outils permettant d’ajouter un aspect serverless à un cluster Kubernetes (vous connaissez mon amour pour k8s, j’ai testé les deux, je conseille les deux)
  • Apache Openwhisk, un provider serverless opensource (à installer sur sa propre infrastructure)
  • AWS Lambda, car après tout, actuellement, AWS, reste le provider préféré des entreprises qui se lancent dans l’aventure serverless