Serverlose Funktionen
Funktion live stellen. Ohne Server.
Verbinde ein Repository, und jeder Push baut eine neue Node.js- oder Python-Version. Jeder aktive Aufruf läuft innerhalb einer eigenen Firecracker-microVM-Grenze, mit Snapshot-Starts und ohne gemeinsam genutzten Anwendungscontainer.
- Etwa 25 Sekunden vom Push bis live
- Die vorherige Version bleibt bei einem Fehler live
- Push empfangen 0.3s
- Node.js-Abhängigkeiten bauen
- v42 aktiviert 24.8s
- POST /hello 200 · 23ms
So funktioniert es
Drei Schritte, danach ist jeder Push live.
Functions folgen demselben Git-zuerst-Ablauf wie der Rest von Sarpius, laufen aber in isolierten microVMs, die für kurzlebige Arbeit gebaut sind.
Repository verbinden
Wähle GitHub, GitLab, Gitea, Bitbucket oder ein beliebiges Standard-Git-Remote. Die Funktion wird Teil deines bestehenden Projects.
function.json hinzufügen
Lege Node.js oder Python, die Einstiegsdatei, die Speicherstufe und das Timeout fest. So bleibt der Laufzeitvertrag beim Code, den er beschreibt.
Pushen und routen
Ein Push baut eine neue unveränderliche Version. Ist sie bereit, schaltet Sarpius den Datenverkehr ohne Ausfallzeit um. Schlägt der Build fehl, bleibt die vorherige Version bestehen.
- GitHub
- GitLab
- Gitea
- Bitbucket
- + beliebiges Remote
In Aktion
Ein Handler, ein kleines Manifest, eine Live-URL.
Das Request-Objekt enthält HTTP-Methode, Pfad, Query, Header und Body. Gib einen Status, Header als Text und einen Body zurück.
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"}Funktionsumfang
Ein vollwertiger Teil deines Projects.
Functions stehen neben deinen Komponenten, Datenbanken und Buckets. Die Konsole hält Bereitstellung, Datenverkehr und Kosten an einem Ort zusammen.
Von Git bis live
Jeder Push auf den konfigurierten Branch startet einen Build. Messungen in der Produktion zeigen, dass eine erfolgreiche Version nach etwa 25 Sekunden live ist.
Atomarer Versionswechsel
Die aktive Version wechselt erst, nachdem der neue Build erfolgreich war. Bestehender Datenverkehr erreicht bis zur Aktivierung weiterhin die vorherige Version.
Teil deines Projects
Functions bekommen einen eigenen Bereich in der Project-Seitenleiste und teilen Routing und Mitglieder mit dem Rest der App.
Ein schlichtes Request-Objekt
Jeder Aufruf erhält Methode, gerouteten Pfad, rohe Query, gefilterte Header und einen UTF-8-Body und gibt einen Status, Header als Text und einen Body zurück.
Logs und Latenz
Lies Build-Logs, aktuelle Aufrufe sowie stündliche Anfrage- und Fehlerzahlen. Die Konsole erfasst die p50- und p95-Latenz der Aufrufe.
Wallet und harte Limits
Die Nutzung wird aus derselben Wallet abgerechnet wie der Rest von Sarpius. Lege ein monatliches Limit in Euro für eine einzelne Funktion oder das gesamte Project fest.
Trigger
Eine Anfrage beantworten oder nach Zeitplan laufen.
Beide Triggertypen nutzen dieselbe aktive Version, dieselben Budgetprüfungen, denselben Nutzungszähler und dieselbe microVM-Isolation.
Eine URL, die zu deinem Project gehört
Nutze eine kostenlose *.sarpius.app-Subdomain oder hänge die Funktion an eine Project-Route wie /api/hello. Methode, Pfad, Query, Header und Body erreichen den Handler.
Geplante Aufgaben ohne Worker
Nutze einen Standard-Cron-Ausdruck mit fünf Feldern und eine IANA-Zeitzone. Füge einer Funktion bis zu 10 Zeitpläne für Berichte, Aufräumarbeiten und wiederkehrende Integrationen hinzu.
Ein reservierter Zeitslot wird nach einem Absturz nie wiederholt. Verpasste Zeitslots werden später nicht nachgeholt, sodass Nebenwirkungen durch eine Wiederherstellung des Planers nicht doppelt ausgeführt werden können.
Preise
Zahle nur für Arbeit, die läuft.
Rechenzeit wird in GiB-Sekunden gemessen, danach kommt die Anzahl der Aufrufe hinzu. Das monatliche Freikontingent wird zuerst angerechnet, auf die Rechnung, die aus deiner Wallet bezahlt wird.
Jeden Monat, vor bezahlter Nutzung
100.000 GiB-Sekunden und 1.000.000 Aufrufe sind kostenlos. Abgerechnet wird in ganzen Cent, abgerundet, und ein Rest bleibt in deiner Nutzung stehen, bis er zusammen einen Cent ergibt. Es gibt keinen Mindestbetrag.
Kleine API
128 MiB, durchschnittlich 200 ms, 1.000.000 Aufrufe
128/1024 × 0,2 × 1.000.000 = 25.000 GiB-s
25.000 liegt unter den 100.000 kostenlosen; 1.000.000 Aufrufe sind kostenlos → €0,00
Fünf Millionen Aufrufe
128 MiB, durchschnittlich 500 ms, 5.000.000 Aufrufe
128/1024 × 0,5 × 5.000.000 = 312.500 GiB-s
(312.500 - 100.000) × €0,000016 = €3,40 Rechenzeit
(5.000.000 - 1.000.000) / 1.000.000 × €0,20 = €0,80 Aufrufe → €4,20
Zwei Millionen Aufrufe
256 MiB, durchschnittlich 1 Sekunde, 2.000.000 Aufrufe
256/1024 × 1 × 2.000.000 = 500.000 GiB-s
(500.000 - 100.000) × €0,000016 = €6,40 Rechenzeit
(2.000.000 - 1.000.000) / 1.000.000 × €0,20 = €0,20 Aufrufe → €6,60
Die Kosten werden von deiner bestehenden Sarpius-Wallet abgebucht. Bei der Abrechnung wird zuerst das monatliche Freikontingent angewendet. Ein Monatslimit lässt sich pro Funktion und pro Project setzen, und seine Sicherheitsprüfung rechnet mit der Bruttonutzung vor Gratisguthaben, kann also früher stoppen als die endgültige Rechnung. Ist ein Limit erreicht oder blockiert die Abrechnung die Funktion, weil die Wallet leer ist, erhalten neue HTTP-Anfragen 402 Payment Required, und es wird keine microVM gestartet.
Leitplanken
Nützlich ist vor allem, was die Laufzeit verweigert.
Diese Grenzen werden vom Dienst durchgesetzt. Es sind keine unverbindlichen Hinweise in einem Dashboard.
Eine microVM-Grenze
Jeder aktive Aufruf bekommt eine Firecracker-microVM-Grenze statt eines gemeinsam genutzten Anwendungscontainers. Warme VMs können nacheinander für dieselbe Funktionsversion wiederverwendet werden, nie gleichzeitig über Kunden hinweg.
Feste Speicherstufen
Wähle 128, 256 oder 512 MiB in function.json. Die Stufe wird für die microVM durchgesetzt und ist auch die Grundlage der Messung in GiB-Sekunden.
Höchstens 60 Sekunden
Ein Manifest kann ein Timeout von 1 bis 60 Sekunden festlegen. Bei einem Timeout folgt 504, und die VM wird zerstört, statt eine unsichere Instanz zurück in den Warm-Pool zu legen.
Die Infrastruktur schlägt geschlossen fehl
Kann die Plattformdatenbank, der Nutzungsschreiber oder der Egress-Wächter des Hosts seine Bereitschaft nicht nachweisen, antwortet der Dienst mit 503 und führt keinen Kundencode kostenlos oder außerhalb der Richtlinie aus.
Das Budget ist ein harter Stopp
Ein erreichtes Funktionslimit, Project-Limit oder eine Abrechnungssperre liefert HTTP 402, bevor eine VM gestartet wird. Die Anfrage läuft nicht weiter und verursacht keine zusätzlichen Kosten.
Cron läuft höchstens einmal
Der Planer vermerkt einen Zeitslot vor dem Versand. Ein Absturz kann einen Lauf verfallen lassen, aber dieser Slot wird nie wiederholt, wenn Nebenwirkungen schon eingetreten sein könnten.
FAQ
Fragen vor dem ersten Push.
Wie schnell geht eine neue Version live?
Messungen in der Produktion zeigen etwa 25 Sekunden vom Push bis zur aktiven Version. Die Build-Zeit hängt weiterhin vom Repository und den Abhängigkeiten ab. Die vorherige Version antwortet weiter, bis die neue aktiv wird.
Was passiert, wenn ein Build fehlschlägt?
Aktiviert wird nur nach einem erfolgreichen Build. Ein fehlgeschlagener Build wird im Project mit seinem Log angezeigt, während die zuletzt aktive Version live bleibt.
Teilen sich zwei Kunden jemals einen Funktionscontainer?
Kein gemeinsam genutzter Anwendungscontainer führt Kundenfunktionen aus. Jeder aktive Aufruf bekommt eine Firecracker-microVM-Grenze. Eine warme VM kann pausiert und später für dieselbe Funktionsversion wiederverwendet werden, wobei ihre Uhr vor dem nächsten Aufruf aktualisiert wird.
Welche Laufzeiten gibt es?
Node.js und Python sind in der geschlossenen Beta verfügbar. Das Manifest verwendet lang: "node" oder lang: "python", mit einem exportierten oder definierten handler(request).
Was erhält eine Funktion von einem HTTP-Trigger?
Der Handler erhält Methode, gerouteten Pfad, rohe Query, gefilterte Header und einen UTF-8-Body. Er gibt einen HTTP-Status, Header-Werte als Text und einen Antwort-Body zurück.
Was passiert am Ausgabenlimit?
Der Dienst liefert HTTP 402, bevor eine microVM gestartet wird. Dieselbe Antwort gilt, wenn die Abrechnung die Funktion blockiert hat, weil die Wallet weitere Nutzung nicht deckt.
Funktion pushen. Project behalten.
Stelle serverlose Arbeit neben dem Code, den Daten, Routen und Menschen bereit, zu denen sie gehört. Bezahle für tatsächliche Ausführung und halte automatisch am Limit an, das du setzt.