Mis à jours 14 juin 2018 Les frameworks sans serveur conçus par soi-même offrent la liberté du verrouillage du cloud, mais au prix de la commodité et de la facilité du cloud.
Le mot “sans serveur” est un mot à la mode et séduisant s’il en est un, car les serveurs sont un peu difficile à supporter. Tous ces correctifs pour ces failles de sécurité sont-ils décrits dans un bazillion mots dans un million de mails reçus dans votre boîte de réception ? Si vous pouviez vous débarrasser d’un serveur, vous pourriez oublier ces correctifs. Qu’en est-il pour tous ces ports sur les pare-feu dont vous devez vous souvenir de garder fermés ? Ils ne seront plus votre souci non plus. Le monde sans serveur vous libérera. Au moins, c’est ce que le mot semble promettre.
Le monde sans serveur a l’air détendu et vous offre plein de temps à consacrer à votre seule véritable mission. Mais, ne soyez pas dupes. Vous paierez cette liberté d’inquiétude en sacrifiant votre liberté d’errer ou de changer. Les plates-formes sans serveur dans les clouds Amazon, Microsoft et Google livrent leur magie à travers une interface propriétaire et chaque fois que vous leur confiez certains de vos soucis, vous devenez accro. Absorbé par les Borg. “Possédé” est un mot trop fort, mais vous pouvez trouver aussi difficile de les échapper.
Les programmeurs détestent ces chaînes et c’est pourquoi un certain nombre d’entre eux essaient de créer des paquets open source qui offrent certaines ou même la plupart des fonctionnalités des plates-formes sans serveur basées sur le cloud, mais dans une pile de code que vous pouvez emporter n’importe où. Non seulement cela facilite le débogage et les tests, mais cela vous permet de prendre votre kit et votre kaboodle dans un autre cloud avec de meilleurs prix, une meilleure latence ou mieux. Vous pourriez même apporter à la maison ce placard climatisé que vous appeliez la salle des serveurs.
Pour maîtriser ce monde en plein essor des frameworks open source sans serveur, voici un aperçu de quatre efforts majeurs : Fission, Fn, Kubeless et OpenWhisk. Sûrement d’autres arriveront bientôt.
Fission
Une solution open source sans serveur de Platform9, Fission combine des conteneurs fonctionnant à l’intérieur de Kubernetes en utilisant des conteneurs standards avec des chargeurs dynamiques. Vos fonctions seront tirées dans le conteneur standard approprié et chargées pour répondre aux requêtes provenant d’un serveur Web qui se trouve déjà dans le conteneur.
Les environnements standards incluent les modèles dominants (Node.js, Python et Go) ainsi que certaines solutions old school comme PHP, .Net, Ruby et même Perl. Bien sûr, vous pouvez aussi construire les vôtres avec n’importe quelle langue, à condition de produire un binaire répondant à une requête HTTP.
La fission est probablement la plus utile pour quiconque veut passer directement au niveau Kubernetes avec les options de mise à l’échelle automatique fournies par l’orchestrateur de conteneur. La fission s’exécute à l’intérieur des clusters Kubernetes en utilisant les outils standard tels que Kubectl, Helm et Tiller.
Un petit exemple sur l’utilisation de l’interface de ligne de commande de Fission pour transformer une fonction simple en un conteneur en cours d’exécution.
Si vous ne pouvez pas compter sur un appel HTTP pour appeler les fonctions, Fission peut les déclencher à partir d’un Crontab ou d’un message de l’un des deux outils de mise en file d’attente pris en charge (Azure Queue Storage ou NATS Streaming). Il y a aussi une option pour définir des “workflows” dans un fichier YAML qui exécutera plusieurs tâches en séquence.
Le plus grand service fourni par Fission est la maintenance de l’ensemble des conteneurs standards qui chargent dynamiquement votre code. Ils sont essentiellement préconfigurés, ce qui vous évite de devoir ajouter le code nécessaire pour fonctionner correctement dans le cluster.
Fn Project
L’entrée d’Oracle dans l’espace sans serveur, Fn, rassemble certains modèles, les routines de construction standard pour les principales langues et certains conteneurs Docker standard. Fn est un peu plus centré sur Java que les autres, pas trop surprenant quand on sait qu’Oracle possède Java. Fn devrait fonctionner avec la plupart des combinaisons de langages et construire des routines aussi longtemps que Docker est à la base. Une partie de la littérature Oracle dit “Une dépendance : Docker”.
Une des fonctionnalités les plus intéressantes est un ensemble de wrappers qui vous permettra d’exécuter votre code AWS Lambda dans la pile locale d’Oracle au lieu de la vôtre. Les fonctions de base sont relativement faciles à cartographier en utilisant ces enveloppes, mais ce n’est souvent qu’une partie de l’image. La plupart des gens utilisent Lambda comme code de collage pour d’autres services cloud Amazon. Ces wrappers vous aident uniquement à récupérer le code Lambda lui-même, vous devrez donc trouver une autre solution pour le levage lourd effectué par les API AWS. Les wrappers sont géniaux, mais leur utilité dépend de la façon dont vous avez conçu votre architecture et du nombre de services Amazon utilisés par votre code.
L’interface de Fn, comme tous ces outils, est toute une ligne de commande. Vous tapez fn, puis ajoutez des commandes pour créer de nouveaux modèles, générer le code résultant, ou éventuellement le déployer. Vous écrivez une fonction simple, c’est un fichier séparé, puis fn va le regrouper avec le bon modèle afin qu’il puisse fonctionner dans un conteneur Docker quelque part.
Les modèles prédéfinis pour Go, Java, Python, Ruby et Node.js sont regroupés en kits de développement Fn (FDK), mais vous n’avez pas besoin de vous concentrer sur eux. Tous vous demandent de créer une fonction qui prend une chaîne comme paramètre et retourne une chaîne comme résultat. Cela ne pourrait pas être plus simple.
Cette interface utilisateur expérimentale dans Fn montre comment un certain nombre de fonctions différentes peuvent être liées ensemble dans un flux de travail.
Lorsque vous déployez le code, Fn le connecte à un déclencheur HTTP qui regroupe tous les paramètres et les transmet à votre fonction qui s’exécute dans un conteneur Docker. À peu près tout le reste est laissé ouvert à vos rêves et conceptions. Oui, Fn vous sauve de tous les maux de tête de déploiement, mais vous devez toujours écrire tout ce code dans cette fonction.
Vous pouvez jouer un peu avec les mécanismes à l’intérieur de Fn. Les informations de gestion interne sont stockées dans une base de données de base (SQL3) utilisée pour le suivi des routes et d’autres informations de déploiement, mais vous pouvez utiliser MySQL ou Postgres immédiatement. Il y a aussi un choix configurable pour la file d’attente de messages qui aide les différentes versions de coordonnées Fn. Vous allez probablement laisser ceux-ci intacts, mais l’option est là si vous en voulez plus.
Fn se sent très léger et simple, sans doute par conception. Il faut quelques outils de construction standard et quelques modèles Docker standard, et les lier ensemble pour qu’il soit plus facile d’écrire un peu de code et de le voir fonctionner dans l’un de ces conteneurs Docker.
Kubeless
Kubeless vient de Bitnami, c’est l’une des entreprises qui nous aide à extraire toute la puissance du cloud avec plusieurs types de produits portables. Comme Fission, Kubeless est conçu pour apporter tout le plaisir de sans serveur aux clusters Kubernetes. Le nom est du genre une plaisanterie, car la technologie est tout sauf Kubernetes. Il s’agit plutôt d’exploiter les fonctionnalités intégrées de Kubernetes pour créer une infrastructure rapide sans serveur.
Kubeless transforme vos fonctions en ressources personnalisées, quelque chose que Kubernetes est conçu pour créer et mettre à l’échelle si nécessaire. Les développeurs semblent préférer Python, ne serait-ce que parce que les exemples y sont largement écrits, mais il y a aussi des temps d’exécution de Node.js, Ruby, PHP, Go et .Net. Bien que Java 1.8 soit absent de certaines parties de la documentation, il est inclus dans la liste des runtimes disponibles en fonction de la version installée.
Les fonctions de base sont un peu plus sophistiquées que dans d’autres frameworks. Chaque fonction que vous écrivez prendra deux paramètres, un objet avec l’événement et un autre objet avec des métadonnées ou un contexte. Ceci permet aux modèles de programmation légèrement plus sophistiqués et auto-conscients que les approches passent juste une chaîne à la fonction. En fin de compte, vous devez renvoyer une chaîne qui sera retournée à n’importe quelle requête HTTP qui a démarré. (Il existe des fonctions d’aide plus agréables dans certaines piles, où l’exécution de Node.js accepte un objet et le sérialise.)
Kubeless a une interface utilisateur qui vous permet de modifier votre fonction, puis de la déployer en un clic.
Si vous ne souhaitez pas déclencher les fonctions à partir d’une requête HTTP, Kubeless peut également être configuré pour répondre aux messages Kafka ou NAT ou à un appel planifié à un moment donné. Vous pouvez également étendre cela en créant une source de ressources personnalisée pour les événements.
L’approche Kubeless sera la plus attrayante pour quiconque qui a complètement maitrisé Kubernetes et se sent à l’aise dans ce monde de clusters et d’auto-scaling. Kubeless est principalement un outil permettant de convertir rapidement le code de base en un cluster Kubernetes répondant à la demande.
OpenWhisk
OpenWhisk est l’outil officiel d’IBM pour la création de Cloud Functions dans IBM Cloud. C’est aussi un projet open source (en statut d’incubation) piloté par Apache Software Foundation. OpenWhisk est en fait une synthèse de plusieurs projets Apache populaires qui sont assemblés pour prendre quelques lignes de votre code, les placer dans des conteneurs Docker et appeler leur exécution via une API REST. Les requêtes sont envoyées par Nginx, transformées en messages Kafka, puis transmises dans les conteneurs. Les informations d’authentification et de gestion sont stockées dans un CouchDB. C’est comme une réunion de Apache Foundation.
Le code lui-même peut être écrit en JavaScript, Java, Python, PHP, Go, et, tout ce que vous savez, même Swift pour ceux qui prennent le temps d’écrire des applications iPhone. Bien sûr, vous pouvez utiliser à peu près tout ce que vous pouvez regrouper dans un conteneur Docker, à condition que les paramètres de la fonction puissent être acceptés par stdin et que les résultats soient transmis via stdout.
Les développeurs OpenWhisk ont essentiellement construit un tas de frameworks standard pour chacun des principaux langages qui prendront quelques textes et les sortiront en utilisant quelques bibliothèques préconfigurées. Lorsque vous écrivez une petite fonction, OpenWhisk la colle dans ce conteneur standard et tout devrait fonctionner – si vous avez suivi les instructions et écrit correctement votre fonction.
Il y aura toujours des défauts. Le code Java s’attend à ce que la bibliothèque Google GSON soit disponible. Le conteneur de votre code Swift exécutera la version open source de Swift, il peut donc y avoir des moments où le code se comporte exactement de la même manière que ce que vous avez expérimenté dans le monde iOS. JavaScript sera probablement l’option la plus populaire pour tout le monde, et votre code JavaScript fonctionnera à l’intérieur du nœud 6 ou 8, qui sont bien compris et prévisibles.
Le chemin d’une requête OpenWhisk : une fois la requête arrivée à la passerelle HTTP, elle passe par Kafka vers les bons paquets Docker.
Il y avait cependant une énorme différence entre l’utilisation d’OpenWhisk dans le cloud bien organisé d’IBM et son exécution sur notre propre machine. L’interface Web d’IBM simplifie l’écriture de quelques lignes et les voit fonctionner correctement. Il faut seulement une demi-heure pour passer de rien à une interface en cours d’exécution qui stocke le texte dans une base de données IBM Cloudant.
Si vous essayez de faire quelque chose de similaire avec la distribution open source, vous devez continuer à courir dans roadblock après roadblock comme la configuration de l’hôte API. La documentation est loin d’être aussi complète qu’elle devrait l’être. Il y a des pointeurs vers plusieurs chemins de démarrage rapide différents, et vous devinerez et remplirez des trous au fur et à mesure.
Il devient rapidement clair qu’il y a pas mal de configuration pour que tout fonctionne sur votre propre machine. Les instructions pour l’empaquetage de votre fonction Swift sont un bon exemple de la façon dont quelques lignes de code prennent beaucoup de configuration et de scripts pour le faire fonctionner.
Sans serveur ou simplicité
Tous ces quatre projets remplissent une niche assez étroite. Le mot « sans serveur » n’est pas utilisé aussi largement qu’il pourrait l’être, et il y a beaucoup d’autres options qui offrent la même flexibilité et la même liberté de scutwork sans porter le mot à la mode « sans serveur ». Les bases de données sont souvent considérées comme l’option sans serveur d’origine et de nombreux systèmes open source comme WordPress, Drupal et Magento sont effectivement sans serveur. Vous les étendez en ajoutant des extraits de PHP qui s’ajustent dans un grand framework. Ce que nous appelions des plug-ins ou des modules pouvait tout aussi bien être commercialisé comme « sans serveur ».
Dans ce contexte, aucun de ces outils n’est aussi sans souci que n’importe laquelle de cette génération de technologie. Ces quatre plates-formes sans serveur sont plus proches d’un gestionnaire amélioré pour les clusters Kubernetes ou Docker. Ils ressemblent plus à des outils de gestion qui simplifient la jonglerie de la configuration que vous devez faire pour configurer et exécuter ces clusters. Ou comme les outils de compilation automatique qui enveloppent votre fonction et l’exécutent sur un cluster.
Les limites de leur rôle sont définies par leur architecture. Les créateurs d’outils visent à offrir une flexibilité maximale. Tous ont une longue liste de langages supportés, mais essaient ensuite d’adoucir l’affaire en disant qu’ils vont travailler avec n’importe quel binaire qui obéit aux règles de formatage pour l’entrée et la sortie. Tout ce qu’ils peuvent faire, c’est coller les pièces ensemble et cracher un conteneur.
Il s’avère que l’obtention des pièces à l’intérieur du conteneur est toujours une énorme partie du défi. Toute la littérature dit que vous pouvez exécuter ces tâches ou actions en écrivant une fonction. Mais, quelle fonction cela peut-il être ? Et ainsi, vous êtes coincé en manipulant tout le travail à l’intérieur du conteneur. Vous devez avoir les bibliothèques et le code à l’intérieur juste avant de passer le contrôle. Et puis, vous devez gérer toutes les autres parties comme les bases de données et les API.
Cela demande beaucoup plus de travail que d’écrire un peu de code pour AWS Lambda, IBM Cloud Functions ou les équivalents de Microsoft Azure et Google Cloud. Lorsque toutes les planètes s’alignent dans ce monde, les services de stockage de données ou d’API du cloud offrent toute la persistance et l’analyse dont vous avez besoin. Vous n’avez vraiment qu’à écrire quelques fonctions simples pour encoder un peu de logique métier et vous avez terminé. Le reste du cloud est là pour faire le travail.
Tous les persistances, les intégrations d’API et les autres échafaudages fournis par les clouds posent un certain défi pour les projets open source. Tous les projets font un bon travail pour prendre votre fonction et la faire fonctionner. Mais, ils ne gèrent pas tout le reste et cela signifie que vous devrez également dupliquer toutes ces autres fonctionnalités. Si vous abandonnez et fuyez les principaux fournisseurs de cloud, vous vous sentirez comme le gamin qui s’enfuit de chez lui avec un sac à dos rempli de Pop Tarts et découvre que la maison est plus que de la nourriture. C’est un lit, une machine à laver, une télévision, une salle de bain, un chien, etc.
