Je ne connaissais pas Firecracker, et l'approche semble très intéressante. Par contre ça limite un environnement Linux (ce qui n'est pas pour me déplaire....).
L'avantage que j'y vois, ce sont les cas un peu limite des conteneurs ou si la volonté d'isolation avec l'hôte est prioritaire. Par contre ça impose plus de travail amont vis-à-vis d'un conteneur sur la question des images (image d'environnement vs image kernel). Sur ce point, la prédominance et la facilité de Docker ou Podman, me semblent dominer.
Quant au démarrage, je pense que c'est un débat d'implémentation. Je ne doute pas que Firecracker ou Qemu soit aussi rapide que Docker, peut-être davantage à la marge des conteneurs (c'est un sentiment, j'ai pas de preuves particulières pour étayer). Docker (ou Podman) peut être très rapide si on passe directement via sa socket et sans demander une conf complexe (ce qui est mon cas).
Là j'ai fait un choix qui est un compromis sur l'implémentation, en passant par une invocation de commande, qui est le pire scénario en lancement individuel ("fonction"), mais très raisonnable pour la partie "service". Par contre je suis plus robuste sur un portage vers d'autres OS - à quelques ajustements prêts.
Autres éléments à prendre en compte : l'API de Firecracker est certes fournie, mais elle correspond à la partie infrastructure / montage de la VM. Ce que je propose là, c'est cette abstraction justement, au profit d'une API qui se concentre sur "ajouter une route qui conduit vers un truc qui porte ma fonction" (avec des délais, une authentification, etc.).
L'API de Firecracker ne gère donc aucun espace de nom pour organiser les microVM et faire la liaison entre une requête entrante / une microVM. Idem pour Qemu avec une socket activation.
Firecracker n'est pas Amazon Lambda, mais seulement un bout de celui-ci. C'est un sous-ensemble parfaitement justifié pour les problématiques d'isolation, mais dans le cas que je présente (réseau privé et/ou de développement), rajoute un élément extérieur à mon binaire solitaire (qui plus est en Go, et la comm' Rust/Go...), sans révolutionner la nature de la problématique métier que je présente.
[^] # Re: MicroVM ?
Posté par JulienG . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été. Évalué à 1.
Je ne connaissais pas Firecracker, et l'approche semble très intéressante. Par contre ça limite un environnement Linux (ce qui n'est pas pour me déplaire....).
L'avantage que j'y vois, ce sont les cas un peu limite des conteneurs ou si la volonté d'isolation avec l'hôte est prioritaire. Par contre ça impose plus de travail amont vis-à-vis d'un conteneur sur la question des images (image d'environnement vs image kernel). Sur ce point, la prédominance et la facilité de Docker ou Podman, me semblent dominer.
Quant au démarrage, je pense que c'est un débat d'implémentation. Je ne doute pas que Firecracker ou Qemu soit aussi rapide que Docker, peut-être davantage à la marge des conteneurs (c'est un sentiment, j'ai pas de preuves particulières pour étayer). Docker (ou Podman) peut être très rapide si on passe directement via sa socket et sans demander une conf complexe (ce qui est mon cas).
Là j'ai fait un choix qui est un compromis sur l'implémentation, en passant par une invocation de commande, qui est le pire scénario en lancement individuel ("fonction"), mais très raisonnable pour la partie "service". Par contre je suis plus robuste sur un portage vers d'autres OS - à quelques ajustements prêts.
Autres éléments à prendre en compte : l'API de Firecracker est certes fournie, mais elle correspond à la partie infrastructure / montage de la VM. Ce que je propose là, c'est cette abstraction justement, au profit d'une API qui se concentre sur "ajouter une route qui conduit vers un truc qui porte ma fonction" (avec des délais, une authentification, etc.).
L'API de Firecracker ne gère donc aucun espace de nom pour organiser les microVM et faire la liaison entre une requête entrante / une microVM. Idem pour Qemu avec une socket activation.
Firecracker n'est pas Amazon Lambda, mais seulement un bout de celui-ci. C'est un sous-ensemble parfaitement justifié pour les problématiques d'isolation, mais dans le cas que je présente (réseau privé et/ou de développement), rajoute un élément extérieur à mon binaire solitaire (qui plus est en Go, et la comm' Rust/Go...), sans révolutionner la nature de la problématique métier que je présente.