Was ist Serverless? Serverless Computing einfach erklärt

Serverless ist eine Art, Code auszuführen, bei der du keine Server selbst einrichtest oder verwaltest. Du übergibst deinen Code einem Cloud-Anbieter, und der führt ihn nur aus, wenn etwas ihn auslöst – eine Webanfrage, eine hochgeladene Datei, eine Zahlungsbenachrichtigung – und hält dann wieder an. Bezahlt wird in der Regel die Zeit, in der dein Code tatsächlich läuft, und nicht eine Maschine, die ungenutzt herumsteht.

Warum Serverless beim Bauen mit KI wichtig ist

Wenn du mit KI eine App baust und dir Hosting-Optionen oder Code ansiehst, stößt du auf „Serverless-Funktionen“, „Edge-Funktionen“ oder „Cloud-Funktionen“. Viele Hosting-Plattformen bieten sie an, und manche KI-Builder stellen Backends so bereit. Das Modell zu verstehen, hilft dir bei drei praktischen Fragen:

• Kosten. Kostet deine App Geld, während niemand sie nutzt?
• Geschwindigkeit. Warum ist die erste Anfrage nach einer ruhigen Phase langsamer?
• Grenzen. Warum ist eine lange Aufgabe – einen großen Bericht erzeugen, ein Video verarbeiten – abgebrochen?

Hilfreich ist auch zu wissen, was Serverless nicht ist: Es ist nicht das Fehlen eines Backends. Du hast weiterhin serverseitigen Code; jemand anders betreibt nur die Maschinen. Die Grundlagen erklärt was ein Server ist.

Ein Alltagsvergleich

Ein klassischer Server ist wie ein eigenes Auto. Es ist immer da und sofort einsatzbereit, aber du zahlst dafür – Versicherung, Stellplatz, Wartung – ob du fährst oder nicht.

Serverless ist wie ein Taxi rufen. Du zahlst nur die Fahrten, die du machst, und wenn hundert Leute gleichzeitig mitfahren wollen, kommen hundert Taxis. Dafür kann es eine kurze Wartezeit geben, bis das Auto kommt (ein Kaltstart), jede Fahrt hat eine maximale Länge, und der Fahrer erinnert sich nicht an dich von der letzten Fahrt (Funktionen sind zustandslos).

So funktionieren Serverless-Funktionen

In der gängigsten Form, genannt Functions as a Service:

1. Du schreibst eine Funktion – ein kleines Stück Code, das eine Art Ereignis behandelt, etwa „verarbeite ein POST an /api/bookings“.
2. Du stellst sie bereit. Der Anbieter speichert sie und verknüpft sie mit einem Auslöser: einer URL, einem Zeitplan, einer neuen Datei im Speicher, einer Nachricht in einer Warteschlange.
3. Ein Ereignis kommt. Der Anbieter startet eine Kopie deiner Funktion (oder nutzt eine bereits warme), führt sie aus und gibt das Ergebnis zurück.
4. Sie skaliert selbstständig. Kommen tausend Anfragen gleichzeitig, führt der Anbieter viele Kopien parallel aus, bis zu den Limits deines Kontos.
5. Sie wird inaktiv. Hört der Verkehr auf, werden die Kopien beendet. Läuft nichts, zahlst du für die Rechenzeit nichts.

Eine winzige Serverless-Funktion in JavaScript könnte so aussehen:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hallo, ${name}` });
}

Es gibt keinen Code, um einen Server zu starten, einen Port zu öffnen oder einen Prozess am Laufen zu halten. Die Plattform übernimmt all das.

„Serverless“ wird auch lockerer für andere verwaltete Dienste verwendet, die automatisch skalieren und nach Nutzung abrechnen – etwa Serverless-Datenbanken, die im Leerlauf pausieren.

Wichtige Begriffe

Ein Beispiel: eine kleine Buchungsseite

Die Buchungsseite eines Yoga-Studios bekommt jeden Sonntagabend einen Schwall an Besuchen, wenn der neue Stundenplan online geht, und den Rest der Woche sehr wenig.

• Mit einem immer laufenden Server zahlt das Studio rund um die Uhr für eine Maschine, die auf den Sonntagabend-Spitzenwert ausgelegt ist und ansonsten meist untätig ist.
• Mit Serverless-Funktionen sind GET /api/classes und POST /api/bookings Funktionen. Der Sonntagsansturm startet automatisch viele Kopien; an einem ruhigen Dienstagmorgen läuft fast nichts, und die Rechnung liegt nahe null.

Die Abwägungen zeigen sich aber auch. Die erste Person, die am Dienstagmorgen die Seite öffnet, wartet vielleicht einen Moment länger wegen eines Kaltstarts. Die Datenbank muss viele kurzlebige Verbindungen von vielen Funktionskopien verkraften, was einen Connection-Pooler nötig machen kann. Und wenn das Studio später eine Aufgabe „erzeuge die jährliche Anwesenheits-PDF für alle“ will, kann sie das Zeitlimit der Funktion überschreiten und muss anderswo laufen.

Wann Serverless passt – und wann nicht

Häufige Irrtümer

• „Serverless bedeutet kein Backend.“ Es bedeutet keine Server, die du verwalten musst. Du schreibst und sicherst weiterhin Backend-Code.
• „Serverless ist immer günstiger.“ Bei geringem Volumen ja, aber die Abrechnung pro Anfrage kann sich bei hohem, gleichbleibendem Volumen stark summieren.
• „Serverless skaliert unendlich.“ Plattformen haben Limits für gleichzeitige Ausführungen, und deine Datenbank kann lange vor den Funktionen zum Engpass werden.
• „Dateien, die eine Funktion speichert, sind beim nächsten Mal noch da.“ Lokaler Speicher ist temporär. Nutze eine Datenbank oder einen Dateispeicher.
• „Auf null skalieren ist dasselbe wie Serverless.“ Verwandt, aber nicht identisch. Manche Plattformen betreiben deine App als gewöhnlichen Server, der bei Leerlauf schläft und bei der nächsten Anfrage aufwacht – ähnliche Einsparungen und eine ähnliche Verzögerung bei der ersten Anfrage, aber ohne die Zeitlimits pro Anfrage, wie sie bei Funktionen gelten.

Was du deinen KI-Builder fragen kannst

• „Läuft dieses Backend als Serverless-Funktionen oder als immer laufender oder schlafender Server? Was bedeutet das für die Kosten?“
• „Werden manche Aufgaben voraussichtlich das Zeitlimit der Plattform überschreiten? Wenn ja, wie lösen wir das?“
• „Speichere alles, was bestehen bleiben muss, in der Datenbank oder im Dateispeicher, nicht im Arbeitsspeicher oder in lokalen Dateien.“
• „Wie sollen die Datenbankverbindungen verwaltet werden, wenn viele Kopien gleichzeitig laufen?“
• „Wie lang ist die Verzögerung bei der ersten Anfrage, nachdem die App inaktiv war?“

Wie Mythex Apps hostet

Mythex beschreibt sein Hosting nicht als Serverless-Funktionen. Beim Veröffentlichen läuft deine App als normale Web-App oder Container, den Mythex für dich verwaltet – du musst kein Hosting einrichten. Es ist Auf-null-Skalierung: Veröffentlichte Apps und ihre Datenbanken schlafen bei Leerlauf und wachen bei der nächsten Anfrage auf, eine schlafende App verbraucht keine Rechenleistung, und zusätzliche Maschinen starten nur bei hoher Last (Pro erlaubt bis zu 3 pro Dienst). Die angebundene Postgres-Datenbank schläft außerdem nach 5 Minuten Inaktivität und wird für die Zeit berechnet, in der sie wach war. Du bekommst also einen Großteil des Vorteils „zahle nur, was du nutzt“, mit derselben Art Verzögerung bei der ersten Anfrage nach einer ruhigen Phase. Siehe Hosting-Limits in der Doku und unsere Leitfäden zu Webhosting und Hosting-Kosten senken.

Fragen