Il y a quelque temps, j’ai lu un article décrivant comment exécuter une fonction Kotlin sans serveur sur OpenFaaS. Bien que le contenu soit techniquement correct, je pense que le concept lui-même est très faux. De tels messages peuvent amener les gens à prendre des décisions peu judicieuses : « parce que nous pouvons » n’est guère une stratégie gagnante. Dans cet article, je voudrais d’abord expliquer pourquoi la plate-forme JVM est une mauvaise idée pour FaaS. Ensuite, je proposerai des alternatives pour utiliser Kotlin néanmoins.
J’ai délibérément choisi de ne pas créer de lien vers le message d’origine pour ne pas lui donner de crédibilité. Si vous voulez quand même le lire, Google est votre ami.
Sémantique
Avant tout, il faut d’abord régler la sémantique du FaaS et du serverless. Bien que les termes soient parfois utilisés de manière interchangeable, j’utiliserai les définitions suivantes dans le cadre de cet article. Dans tous les cas, il est toujours utile de jeter un œil à ce sur quoi les gens sur Wikipédia se sont mis d’accord :
L’informatique sans serveur est un modèle d’exécution de cloud computing dans lequel le fournisseur de cloud exécute le serveur et gère dynamiquement l’allocation des ressources de la machine. La tarification est basée sur la quantité réelle de ressources consommées par une application, plutôt que sur des unités de capacité pré-achetées.
— Informatique sans serveur
La fonction en tant que service (FaaS) est une catégorie de services de cloud computing qui fournit une plate-forme permettant aux clients de développer, d’exécuter et de gérer des fonctionnalités d’application sans la complexité de créer et de maintenir l’infrastructure généralement associée au développement et au lancement d’une application.
— Fonctionner en tant que service
D’après les définitions ci-dessus :
-
Le sans serveur concerne la gestion des ressources :
Vous devez le gérer de manière dynamique, la propriété étant l’élasticité.
-
FaaS correspond à la taille du code :
L’évolution des tailles va d’une application à part entière aux microservices à une fonction. Le message d’origine le mentionne.
Ergo, FaaS implique sans serveur.
La JVM et le FaaS
Les JVM la plate-forme est une belle pièce de technologie. En particulier, la couche d’abstraction permet à la JVM de compiler les bytecode en code natif adapté à la charge de travail. C’est la raison pour laquelle même si les applications compilées en C/C++ sont plus proches du bare metal, la JVM a pu rivaliser avec elles en termes de performances – et même gagner.
Cependant, cette optimisation a un coût : la JVM a besoin de temps pour se réchauffer, par exemple, pour charger des classes en mémoire. C’est pourquoi les tests de performances sur la JVM nécessitent quelques cycles de préchauffage. Pour cette raison, la JVM est bien adaptée aux processus de longue durée, où le temps de démarrage est négligeable par rapport à la durée de vie globale du processus. Les serveurs d’applications sont l’enfant de l’affiche de tels cas d’utilisation : une fois démarrés, il faut les exécuter pendant longtemps, disons des jours, pour être très conservateur. À cet égard, un temps de démarrage d’une minute ne veut rien dire.
Vient maintenant FaaS : dans le contexte JVM, FaaS signifie que la JVM démarre, la fonction s’exécute et tout est supprimé juste après. Dans ce cas, le temps de démarrage a un impact significatif sur le temps d’exécution global. De plus, la JVM n’a pas le temps de compiler les bytecode au code natif : il reste « froid ».
Certains recommandent de conserver la JVM pour la réutiliser par la suite et ainsi éviter de payer le coût du temps de démarrage. C’est assez simple pour y parvenir : il suffit d’envoyer des requêtes à la fonction plus rapidement que le rythme auquel le fournisseur FaaS supprime la JVM sous-jacente. Cependant, cela va à l’encontre de l’objectif du sans serveur, car la propriété d’élasticité a maintenant disparu.
Il s’applique à Kotlin, Java, Scala, Groovy, Clojure et à tous les autres langages qui s’exécutent sur la JVM. Même si j’aime Kotlin, c’est interdit : quiconque dit le contraire n’a pas besoin de l’élasticité que l’approche FaaS fournit – ou pire, n’en a aucune idée. Cela reviendrait à construire une architecture de microservices dans la plupart des contextes : C’est à dire..
Le meilleur des deux mondes
Et pourtant, tout espoir n’est pas perdu. Il existe des moyens d’utiliser Kotlin tout en pouvant bénéficier de FaaS. Puisque le problème avec FaaS est la JVM, pourquoi ne pas la supprimer ? Il y a deux façons simples d’y parvenir :
-
Utilisez l’image native de Graal :
GraalVM est un ensemble de technologies différentes. Parmi eux, SubstrateVM : il permet de transformer un JAR (ou une classe) en un exécutable natif. Vous pouvez ensuite encapsuler l’application résultante dans un conteneur Docker, qui doit être compatible avec le framework FaaS de votre choix. Voici un exemple d’une telle approche.
-
Transpiler en JavaScript :
Une autre alternative consiste à transpiler Kotlin en JavaScript. JavaScript n’a pas besoin de la plate-forme JVM pour fonctionner. Ensuite, le code peut être emballé dans un conteneur comme ci-dessus ou emballé directement dans une archive ZIP. Cette dernière option peut s’exécuter sur des infrastructures propriétaires, telles que AWS Functions.
Les deux approches nécessitent un pipeline de construction solide pour commencer à partir de Kotlin et se terminer avec un conteneur Docker (ou un ZIP). Comme pour la conception d’origine, ils ont besoin à la fois de tests unitaires pour tester que le code est correct et de tests d’intégration pour tester l’artefact final fonctionne comme prévu.
Conclusion
Il faut être conscient du contexte de la plupart des technologies. Vous n’avez (probablement) pas besoin de microservices, de FaaS ou de toute autre tendance actuelle. Cependant, en comprenant les avantages et les inconvénients de ceux-ci, vous pourrez les exploiter au moment opportun.
Pour l’instant, il serait déconseillé d’utiliser la JVM avec FaaS. Cela ne signifie pas que vous ne pouvez pas du tout utiliser Kotlin.