Fonctions serverless
Publiez une fonction. Oubliez le serveur.
Connectez un dépôt et chaque push construit une nouvelle version Node.js ou Python. Chaque appel actif s'exécute dans sa propre frontière microVM Firecracker, avec des démarrages à partir de snapshots et sans conteneur applicatif partagé.
- Environ 25 secondes du push à la mise en ligne
- La version précédente reste en ligne en cas d'échec
- Push reçu 0.3s
- Construction des dépendances Node.js
- v42 activée 24.8s
- POST /hello 200 · 23ms
Comment ça marche
Trois étapes, puis chaque push est en ligne.
Functions suit le même parcours git d'abord que le reste de Sarpius, mais déploie dans des microVM isolées, conçues pour des tâches de courte durée.
Connectez votre dépôt
Choisissez GitHub, GitLab, Gitea, Bitbucket ou n'importe quel remote git standard. La fonction fait partie de votre Project existant.
Ajoutez function.json
Déclarez Node.js ou Python, le fichier d'entrée, le palier de mémoire et le délai d'expiration. Le contrat d'exécution reste avec le code qu'il décrit.
Poussez et routez
Un push construit une nouvelle version immuable. Quand elle est prête, Sarpius bascule le trafic sans interruption et laisse la version précédente en place si la construction échoue.
- GitHub
- GitLab
- Gitea
- Bitbucket
- + remote générique
En action
Un handler, un petit manifeste, une URL en ligne.
L'objet request porte la méthode HTTP, le chemin, la query, les en-têtes et le corps. Renvoyez un statut, des en-têtes sous forme de texte et un corps.
export async function handler(request) {
const input = request.body
? JSON.parse(request.body)
: {};
return {
status: 200,
headers: {
"content-type": "application/json"
},
body: JSON.stringify({
message: `Hello, ${input.name ?? "world"}`,
method: request.method,
path: request.path
})
};
}{
"lang": "node",
"tier": 128,
"entry": "index.mjs",
"timeout_s": 10
}$ curl -X POST \
-H "content-type: application/json" \
-d '{"name":"Ada"}' \
https://hello-function.sarpius.app/hello
{"message":"Hello, Ada","method":"POST","path":"/hello"}Fonctionnalités
Une partie à part entière de votre Project.
Functions se place à côté de vos composants, bases de données et buckets. La console réunit au même endroit le déploiement, le trafic et le coût.
De git à la mise en ligne
Chaque push sur la branche configurée lance une construction. Les mesures en production donnent une version réussie en ligne en environ 25 secondes.
Bascule de version atomique
La version active ne change qu'une fois la nouvelle construction réussie. Le trafic existant continue d'atteindre la version précédente jusqu'à l'activation.
Intégré au Project
Functions a sa propre section dans la barre latérale du Project et partage le routage et les membres avec le reste de l'application.
Un simple objet request
Chaque appel reçoit la méthode, le chemin routé, la query brute, les en-têtes filtrés et un corps UTF-8, et renvoie un statut, des en-têtes sous forme de texte et un corps.
Journaux et latence
Consultez les journaux de construction, les appels récents et les nombres de requêtes et d'erreurs par heure. La console suit la latence p50 et p95 des appels.
Wallet et plafonds stricts
La consommation est prélevée sur le même wallet que le reste de Sarpius. Fixez une limite mensuelle en euros pour une fonction ou pour tout le Project.
Déclencheurs
Répondre à une requête ou s'exécuter selon un calendrier.
Les deux types de déclencheur utilisent la même version active, les mêmes contrôles de budget, le même compteur d'usage et la même isolation microVM.
Une URL qui appartient à votre Project
Utilisez un sous-domaine *.sarpius.app gratuit ou montez la fonction sur une route du Project comme /api/hello. La méthode, le chemin, la query, les en-têtes et le corps parviennent au handler.
Des tâches planifiées sans worker
Utilisez une expression cron standard à cinq champs et un fuseau horaire IANA. Ajoutez jusqu'à 10 planifications à une fonction pour des rapports, du nettoyage et des intégrations récurrentes.
Un créneau réservé n'est jamais rejoué après un plantage. Les créneaux manqués ne sont pas rattrapés plus tard, si bien qu'une reprise du planificateur ne peut pas exécuter deux fois des effets de bord.
Tarification
Ne payez que le travail qui s'exécute.
Le calcul se mesure en GiB-secondes, puis le nombre d'appels s'y ajoute. Le quota gratuit mensuel s'applique en premier, sur la facture réglée par votre wallet.
Chaque mois, avant l'usage payant
100 000 GiB-secondes et 1 000 000 d'appels sont gratuits. La facturation se fait en centimes entiers, arrondis à l'inférieur, et un reste demeure dans votre usage jusqu'à former un centime. Il n'y a pas de montant minimum.
Petite API
128 MiB, 200 ms en moyenne, 1 000 000 d'appels
128/1024 × 0,2 × 1 000 000 = 25 000 GiB-s
25 000 est sous les 100 000 gratuits ; 1 000 000 d'appels sont gratuits → €0,00
Cinq millions d'appels
128 MiB, 500 ms en moyenne, 5 000 000 d'appels
128/1024 × 0,5 × 5 000 000 = 312 500 GiB-s
(312 500 - 100 000) × €0,000016 = €3,40 de calcul
(5 000 000 - 1 000 000) / 1 000 000 × €0,20 = €0,80 d'appels → €4,20
Deux millions d'appels
256 MiB, 1 seconde en moyenne, 2 000 000 d'appels
256/1024 × 1 × 2 000 000 = 500 000 GiB-s
(500 000 - 100 000) × €0,000016 = €6,40 de calcul
(2 000 000 - 1 000 000) / 1 000 000 × €0,20 = €0,20 d'appels → €6,60
Les frais sont débités de votre wallet Sarpius existant. La facturation applique d'abord le quota gratuit mensuel. Un plafond mensuel peut être fixé par fonction et par Project ; son contrôle de sécurité compte l'usage brut avant les crédits gratuits, il peut donc s'arrêter plus tôt que la facture finale. Quand un plafond est atteint, ou quand la facturation bloque la fonction parce que le wallet est vide, les nouvelles requêtes HTTP reçoivent 402 Payment Required et aucune microVM n'est démarrée.
Garde-fous
Ce qui compte, c'est ce que l'exécution refuse.
Ces limites sont appliquées par le service. Ce ne sont pas de simples conseils dans un tableau de bord.
Une frontière microVM
Chaque appel actif obtient une frontière microVM Firecracker au lieu d'un conteneur applicatif partagé. Les VM chaudes peuvent être réutilisées l'une après l'autre pour la même version de fonction, jamais en même temps entre clients.
Des paliers de mémoire fixes
Choisissez 128, 256 ou 512 MiB dans function.json. Le palier est appliqué à la microVM et sert aussi de base à la mesure en GiB-secondes.
60 secondes au maximum
Un manifeste peut fixer un délai d'expiration de 1 à 60 secondes. Un dépassement renvoie 504 et détruit la VM, au lieu de remettre une instance incertaine dans le pool chaud.
L'infrastructure échoue en mode fermé
Si la base de données de la plateforme, l'écrivain d'usage ou la garde de sortie de l'hôte ne peut pas prouver qu'il est prêt, le service renvoie 503 et n'exécute pas de code client gratuitement ou hors politique.
Le budget est un arrêt strict
Un plafond de fonction ou de Project atteint, ou un blocage de facturation, renvoie HTTP 402 avant qu'une VM soit obtenue. La requête ne continue pas et ne génère pas de dépense supplémentaire.
Cron s'exécute au plus une fois
Le planificateur enregistre un créneau avant l'envoi. Un plantage peut laisser une exécution abandonnée, mais ce créneau n'est jamais rejoué quand des effets de bord ont pu déjà se produire.
FAQ
Des questions avant le premier push.
En combien de temps une nouvelle version est-elle en ligne ?
Les mesures en production donnent environ 25 secondes entre le push et la version active. Le temps de construction dépend toujours du dépôt et de ses dépendances. La version précédente continue de répondre jusqu'à l'activation de la nouvelle.
Que se passe-t-il quand une construction échoue ?
L'activation n'a lieu qu'après une construction réussie. Une construction échouée s'affiche dans le Project avec son journal, tandis que la dernière version active reste en ligne.
Deux clients partagent-ils jamais un conteneur de fonction ?
Aucun conteneur applicatif partagé n'exécute les fonctions des clients. Chaque appel actif obtient une frontière microVM Firecracker. Une VM chaude peut être mise en pause puis réutilisée plus tard pour la même version de fonction, avec son horloge rafraîchie avant l'appel suivant.
Quels runtimes sont disponibles ?
Node.js et Python sont disponibles dans la bêta fermée. Le manifeste utilise lang: "node" ou lang: "python", avec un handler(request) exporté ou défini.
Que reçoit une fonction d'un déclencheur HTTP ?
Le handler reçoit la méthode, le chemin routé, la query brute, les en-têtes filtrés et un corps UTF-8. Il renvoie un statut HTTP, des valeurs d'en-tête sous forme de texte et un corps de réponse.
Que se passe-t-il à la limite de dépenses ?
Le service renvoie HTTP 402 avant d'obtenir une microVM. La même réponse est utilisée quand la facturation a bloqué la fonction parce que le wallet ne peut pas couvrir un usage supplémentaire.
Besoin de détails ? Consultez la documentation de Sarpius Functions.
Poussez la fonction. Gardez le Project.
Déployez le travail serverless à côté du code, des données, des routes et des personnes auxquels il appartient. Payez l'exécution réelle et arrêtez-vous automatiquement à la limite que vous fixez.