Was ist Serverless? Cold Start und die wahren Kosten der Architektur

Was ist Serverless?

Serverless ist ein Cloud Modell, bei dem Sie Code ausführen, ohne Server selbst einzurichten oder zu betreiben. Zudem übernimmt der Anbieter Infrastruktur, Skalierung und Updates. Ihr Code läuft, wenn ein Ereignis eintrifft, und stoppt, sobald die Arbeit erledigt ist. Sie zahlen also meist für Laufzeit und Aufrufe, nicht für ungenutzte Kapazität.

Der Name führt ein wenig in die Irre, denn Server gibt es weiterhin. Der Unterschied liegt darin, dass der Anbieter sie betreibt und nicht Sie.

In diesem Leitfaden klären wir, was ist Serverless, und den Begriff, der ständig mitläuft: den Cold Start. Nachbarbegriffe wie Event Driven Architecture und WebAssembly streifen wir nur kurz und verweisen auf eigene Beiträge.

Unser Ziel ist einfach, denn Klarheit zählt mehr als Fachjargon. Am Ende sollen Sie sagen können, was Serverless Ihnen bringt, was es verbirgt und für welche Aufgaben es passt. Die Details halten wir daher auf Konzeptebene. Konkrete Grenzwerte überlassen wir der offiziellen Dokumentation der Anbieter.

Was ist Serverless, erklärt mit einem Vergleich?

Stellen Sie sich vor, Sie brauchen in einer großen Stadt ein Auto. Ein eigenes Auto bedeutet Kauf, Versicherung, Wartung und die ewige Parkplatzsuche. Ein Taxi ist dagegen anders, denn es kennt keine Fixkosten. Sie zahlen nur für die Fahrt, und die Wartung ist nicht Ihr Problem.

Ein klassischer Server gleicht dem eigenen Auto. Somit kostet er Geld, auch wenn er nachts in der Garage steht. Serverless gleicht dem Taxi: Es kommt, wenn Sie rufen, und fährt weg, wenn Sie fertig sind.

Der Vergleich hat allerdings einen Haken. Beim ersten Anruf warten Sie ein wenig auf das Taxi. Dieses Warten ist also der Cold Start. Wer ein Auto dauerhaft mit laufendem Motor bereithält, spart sich die Wartezeit, zahlt dafür aber wieder die Kosten.

Die ehrliche Antwort auf die Frage, was ist Serverless, enthält also Komfort und Preis zugleich. Allerdings ist ein Taxi nicht auf jeder Strecke günstiger. Wer den ganzen Tag unterwegs ist, fährt mit einem eigenen Wagen oft besser.

Ist Serverless wirklich ohne Server?

Nein. Ihr Code läuft dennoch weiterhin auf einer physischen Maschine, meist in einer isolierten Umgebung. Es ändert sich also die Verteilung der Verantwortung. Betriebssystem Updates, Sicherheitspatches, Kapazitätsplanung und Skalierungsentscheidungen liegen beim Anbieter.

Bei Ihnen dagegen bleiben Code, Konfiguration, Berechtigungen und Daten. Das heißt, der Verwaltungsaufwand sinkt, aber die Verantwortung verschwindet nicht. Eine Sicherheitslücke in Ihrem Code oder eine zu großzügige Berechtigung bleibt Ihre Sache.

Deshalb lohnt es sich, das früh zu klären. Kurz gesagt: Serverless ist keine Magie, sondern Arbeitsteilung. Somit schätzt ein Team, das weiß, wer welche Ebene verantwortet, Kosten und Risiko genauer ein.

Außerdem hilft diese Sicht im Gespräch mit dem Anbieter. Wenn etwas ausfällt, wissen Sie, welche Ebene wem gehört, und wenden sich an die richtige Stelle.

Wie funktioniert Serverless?

Den Ablauf können Sie in vier Schritten beschreiben, und zwar so: Zunächst trifft ein Ereignis ein. Das kann eine Webanfrage, ein Datei Upload, ein Zeitgeber oder eine Nachricht aus einer Warteschlange sein. Danach sucht der Anbieter für dieses Ereignis eine bereite Ausführungsumgebung.

1. Ereignis: Ein Auslöser ruft Ihre Funktion auf.
2. Umgebung vorbereiten: Der Anbieter nimmt Ihren Code, startet die Umgebung und führt Ihren Startcode aus.
3. Ausführung: Ihre Funktion bearbeitet die Anfrage und liefert eine Antwort.
4. Wartezeit oder Abschluss: Der Anbieter hält die Umgebung eine Weile bereit und schließt sie, wenn keine neue Anfrage kommt.

Entscheidend ist dabei der Übergang zwischen Schritt drei und vier. Solange die Umgebung wartet, kann eine neue Anfrage sie also wiederverwenden. Folglich endet die zweite Anfrage meist schneller.

Zum Beispiel beschreibt die Dokumentation von AWS Lambda diesen Lebenszyklus mit den Phasen Init, Invoke und Shutdown. Außerdem erneuert der Anbieter Umgebungen regelmäßig. Gehen Sie deshalb nie davon aus, dass eine Umgebung ewig lebt.

Was sind FaaS und BaaS, und wie hängen sie mit Serverless zusammen?

Unter dem Dach von Serverless liegen zwei Hauptideen. Weil man sie oft verwechselt, trennen wir sie hier.

• FaaS (Function as a Service): Sie führen kleine Codestücke als Reaktion auf Ereignisse aus. Die Umgebung verwaltet dann der Anbieter.
• BaaS (Backend as a Service): Sie nutzen fertige Dienste wie Anmeldung, Datenbank und Dateispeicher über Schnittstellen. Eigenen Servercode dafür schreiben Sie somit nicht.

In der Praxis arbeiten beide nebeneinander. Zum Beispiel löst eine mobile App die Anmeldung über BaaS und führt eine eigene Geschäftsregel in einer FaaS Funktion aus.

Wer allgemein fragt, was ist Serverless, meint meist FaaS. Die Definition umfasst allerdings auch BaaS. Gemeinsam ist beiden also, dass Sie die Infrastruktur nicht verwalten.

Einen weiteren Unterschied sollten Sie kennen. Bei FaaS schreiben Sie den Code selbst. Bei BaaS dagegen hat der Anbieter den größten Teil geschrieben. Deshalb startet BaaS schneller, lässt aber weniger Spielraum.

Welche Cloud Anbieter bieten Serverless an?

Alle großen Cloud Anbieter haben dieses Modell im Programm. AWS Lambda, Azure Functions und Dienste von Google Cloud wie Cloud Run setzen dieselbe Idee unter verschiedenen Namen um. Das Prinzip ist gleich: Sie laden Code hoch, verbinden einen Auslöser, und der Anbieter kümmert sich um die Skalierung.

Allerdings stecken die Unterschiede im Detail. Jeder Anbieter hat eigene Grenzen für die Laufzeit, unterstützte Sprachen, Auslöser und eine eigene Preisstruktur. Außerdem benennt sogar ein einzelner Anbieter Produkte und Tarife im Lauf der Zeit um.

Stützen Sie sich deshalb nicht auf Produktnamen oder Grenzwerte. Öffnen Sie bei der Entscheidung die offizielle Dokumentation und lesen Sie dort den aktuellen Tarif.

Wir stellen in diesem Beitrag keinen Anbieter in den Vordergrund. Uns geht es daher um Begriffe, die unabhängig von der Wahl gelten. Die Antwort auf die Frage, was ist Serverless, hängt nicht vom Hersteller ab. Nur die Namen der Schaltflächen und die Preistabellen ändern sich dagegen.

Was ist ein Cold Start und warum entsteht er?

Ein Cold Start ist die zusätzliche Verzögerung, wenn eine Funktion nach längerer Pause ihre erste Anfrage erhält. Denn zu diesem Zeitpunkt gibt es keine bereite Ausführungsumgebung. Der Anbieter lädt Ihren Code, startet die Umgebung und führt Ihren Startcode aus. Erst danach bearbeitet er Ihre Anfrage.

Bedient dieselbe Umgebung kurz darauf eine weitere Anfrage, sprechen wir von einem Warm Start. Dann entfallen die Vorbereitungsschritte, und die Antwort kommt schneller.

Die AWS Dokumentation beschreibt, dass Cold Starts nur einen kleinen Anteil der Aufrufe betreffen und in Entwicklungsumgebungen mit wenig Verkehr häufiger auftreten. Der Grund ist einfach, denn eine selten aufgerufene Funktion verliert ihre Umgebung vor dem nächsten Aufruf.

Ein Cold Start ist also kein Fehler, sondern eine natürliche Folge des Modells. Die eigentliche Frage lautet daher, wie stark Nutzer ihn spüren. Bemerkt ihn niemand, müssen Sie nicht dagegen ankämpfen.

Wovon hängt die Dauer eines Cold Starts ab?

Eine feste Dauer gibt es allerdings nicht. Die Verzögerung hängt von Ihrem Code und Ihrer Umgebung ab. Laut AWS Dokumentation entsteht der größte Teil der Startlatenz im Initialisierungscode.

• Paketgröße: Je mehr Bibliotheken und Abhängigkeiten Sie einbinden, desto länger dauern Download und Laden.
• Startarbeit: Code außerhalb der eigentlichen Funktion baut Verbindungen auf und liest Konfigurationen.
• Laufzeitumgebung: Manche Sprachen und Frameworks brauchen eine aufwendigere Vorbereitung.
• Netzwerkeinstellungen: Funktionen in einem privaten Netzwerk brauchen unter Umständen zusätzliche Vorbereitung.
• Speicher und Rechenanteil: Die zugewiesenen Ressourcen können die Startzeit beeinflussen.

Die genauen Werte unterscheiden sich je nach Anbieter und ändern sich mit der Zeit. Statt nach Zahlen zu suchen, messen Sie lieber Ihre eigene Funktion. Das ist somit der verlässlichste Weg.

Schauen Sie beim Messen nicht nur auf den Durchschnitt. Ein Cold Start betrifft wenige Anfragen, daher verschwindet er im Mittelwert. Erst die Messung der langsamsten Anfragen zeigt dann das echte Bild.

Wie verringern Sie einen Cold Start?

Die Lösungen fallen in zwei Gruppen: die Startarbeit verkleinern oder Umgebungen bereithalten. Zunächst ist es sinnvoll, mit den kostenlosen Optionen zu beginnen.

• Paket verkleinern: Binden Sie nur Bibliotheken ein, die Sie wirklich nutzen. Auch das Aufteilen einer großen Funktion in kleinere, gezielte Funktionen hilft.
• Startcode vereinfachen: Verschieben Sie Arbeit, die nicht jede Anfrage braucht, auf den ersten Moment des Bedarfs. Das nennt man also Lazy Loading.
• Verbindungen wiederverwenden: Öffnen Sie Ressourcen wie Datenbankverbindungen außerhalb der Funktion, damit warme Umgebungen sie erneut nutzen.
• Bereite Instanzen halten: Provisioned Concurrency bei AWS, Always Ready Instanzen bei Azure und Mindestinstanzen bei Google Cloud Run dienen genau diesem Zweck.
• Schnappschüsse nutzen: Funktionen wie AWS SnapStart speichern ein Abbild einer vorbereiteten Umgebung und setzen dort wieder an.

Bedenken Sie jedoch, dass bereite Instanzen nicht kostenlos sind. Auch Google weist darauf hin, dass Mindestinstanzen im Leerlauf Kosten verursachen.

Wann lohnt es sich, Instanzen bereitzuhalten?

Eine bereite Instanz verringert Cold Starts, bringt aber feste Kosten mit. Damit geht einer der größten Reize von Serverless teilweise verloren, nämlich nichts im Leerlauf zu zahlen. Dieser Tausch lohnt sich daher nicht für jede Funktion.

Diese Fragen helfen bei der Entscheidung:

• Liegt die Funktion auf einem Pfad, auf den der Nutzer wartet?
• Schadet die Verzögerung sichtbar der Conversion oder dem Erlebnis?
• Lässt sich der Verkehr vorhersagen, sodass Sie Instanzen nur zu Stoßzeiten bereithalten?
• Handelt es sich um einen Hintergrundjob oder um eine Nutzeranfrage?

Bei Hintergrundjobs sind bereite Instanzen deshalb meist unnötig. Auf dem Nutzerpfad sorgt dagegen ein kleiner warmer Pool für ein gleichmäßigeres Erlebnis.

Messen Sie zuerst, entscheiden Sie dann. Wer ohne Messung warme Instanzen hinzufügt, löst womöglich nichts und erzeugt nur eine weitere Rechnungsposition. Legen Sie außerdem eine Testphase fest. Beobachten Sie zum Beispiel zwei Wochen lang die echte Nutzerlatenz und bestimmen Sie die Poolgröße anhand dieser Daten.

Wie wirkt sich ein Cold Start auf Ladezeit und SEO aus?

Läuft eine Seite oder eine Schnittstelle über eine Serverless Funktion, addiert sich der Cold Start zur Zeit bis zum ersten Byte. Folglich kann sich das Laden der Seite langsamer anfühlen. Das kann dann in den Core Web Vitals sichtbar werden.

Allerdings liegt nicht jede Funktion auf dem Nutzerpfad. Bei einem nächtlichen Berichtsjob spielt eine kleine Zusatzverzögerung keine Rolle. Bei einer Funktion, die eine Produktseite erzeugt, bemerken Besucher dieselbe Verzögerung dagegen sehr wohl, weil sie warten.

Teilen Sie Ihre Funktionen daher in zwei Gruppen: Pfade, auf die Nutzer warten, und Hintergrundarbeit. Seien Sie zunächst bei der ersten Gruppe streng mit der Latenz. Bei der zweiten können Sie Cold Starts gelassen sehen.

Die allgemeine Logik der Geschwindigkeit haben wir in wie die Ladezeit SEO beeinflusst erklärt. Seiten vorab zu erzeugen und zwischenzuspeichern ist ein weiterer gängiger Weg, Cold Starts vor Besuchern zu verbergen. Die Funktion läuft dann nur für Anfragen ohne Zwischenspeicher, und die meisten Besucher erhalten eine fertige Antwort.

Wie unterscheidet sich eine Edge Function von einer Serverless Funktion?

Eine Edge Function ist eine Serverless Variante, die Ihren Code an verteilten Punkten nahe beim Nutzer ausführt statt in einer zentralen Region. Das Ziel ist also, die Verzögerung durch Entfernung zu senken. Die Grundlogik der Verzögerung lesen Sie in unserem Beitrag zu Ping und Latenz.

Der Unterschied zeigt sich an einigen Stellen:

• Ort: Eine klassische Funktion läuft in der Region, die Sie wählen. Eine Edge Function läuft am Rand des Netzes.
• Start: Edge Umgebungen sind meist leichter gebaut, daher bleibt die Vorbereitungszeit tendenziell kurz.
• Grenzen: Verfügbare Bibliotheken, Laufzeit und Speicher sind oft enger gefasst.
• Einsatz: Weiterleitungen, Prüfungen der Anmeldung, Änderungen an Headern und einfache Personalisierung passen gut.

Für schwere Datenbankarbeit ist der Edge allerdings nicht der richtige Ort. Liegen die Daten in einer Region, bringt der Weg zu diesen Daten die Verzögerung zurück, auch wenn der Code am Rand läuft.

Wie schneidet Serverless gegenüber VPS und Containern ab?

Alle drei Modelle führen Code aus, doch Verantwortung und Abrechnung unterscheiden sich. Die folgende Tabelle ist ein Vergleich auf Konzeptebene. Sie enthält keine Zahlen, weil Preise je nach Anbieter schwanken.

Container haben wir in Was ist Docker erklärt, den Unterschied zwischen VPS und Cloud Server in unserer Entscheidungshilfe zu VPS, VDS und Cloud Server.

Trotzdem gewinnt keines der drei Modelle immer. Die Form Ihrer Last, die Erfahrung Ihres Teams und die Flexibilität Ihres Budgets verschieben die Tabelle. Als Vergleich mit festem Server dient unsere Anleitung zum Next.js Deployment auf dem VPS.

Was ist Serverless bei den Kosten, wenn der Verkehr schwankt oder gleichmäßig bleibt?

Die Abrechnung bei Serverless besteht meist aus zwei Teilen: der Zahl der Aufrufe und dem Ressourcenverbrauch über die Laufzeit. Kommen keine Anfragen, sinkt die Rechnung folglich stark. Das ist für Projekte mit unvorhersehbarem oder stoßweisem Verkehr attraktiv.

Bei gleichmäßig hohem Verkehr dagegen kann das Bild kippen. Läuft eine Funktion den ganzen Tag ohne Pause, kann Bezahlung nach Nutzung teurer sein als ein fester Server. Denn diesen Server hätten Sie ohnehin ausgelastet.

Beispielszenario: Denken Sie an einen Formulardienst, der in Kampagnenzeiten stark gefragt ist und sonst ruhig bleibt. Also: In den ruhigen Zeiten nichts zu zahlen, ist ein großer Vorteil. Eine Schnittstelle, die jede Sekunde dieselbe Last trägt, ist mit fester Kapazität dagegen oft besser planbar.

Vergessen Sie außerdem versteckte Posten nicht. Datenausgang, Aufbewahrung von Protokollen, Warteschlangen und API Gateways können die Rechnung zusätzlich erhöhen. Prüfen Sie aktuelle Preise und kostenlose Kontingente immer auf der offiziellen Preisseite des Anbieters.

Warum ist die Anbieterbindung bei Serverless besonders sichtbar?

Jeder Anbieter hat eigene Auslöser, ein eigenes Konfigurationsformat, ein eigenes Berechtigungssystem und eigene Hilfsdienste. Zum Beispiel mag Ihr Funktionscode übertragbar aussehen. Trotzdem lassen sich Warteschlange, Speicher und Identitätsschicht drumherum nicht einfach mitnehmen. Diese Abhängigkeit nennen wir Anbieterbindung, im Englischen Vendor Lock in.

Ganz beseitigen können Sie sie nicht, aber Sie können sie verringern:

• Halten Sie die Geschäftslogik als schlichten Code getrennt vom Anbieter.
• Bündeln Sie anbieterspezifischen Code in einer dünnen Adapterschicht.
• Bevorzugen Sie offene Standards wie HTTP und gängige Ereignisformate.
• Schätzen Sie die Kosten eines Wechsels früh ein, auch grob.

Manchmal ist die Bindung allerdings ein vertretbarer Preis. Gewinnen Sie Tempo und kennen Sie den Ausweg, bleibt das Risiko beherrschbar. Wichtig ist daher, dass Sie sich bewusst dafür entscheiden.

Container basierte Aufbauten sind hier flexibler. Denselben Container können Sie zwischen Umgebungen verschieben, daher ist der Ausgang breiter.

Welche Grenzen und Risiken hat Serverless?

Allerdings löst Serverless nicht jedes Problem. Es bringt Einschränkungen mit, und wer sie früh kennt, vermeidet teure Neuentwicklungen.

• Grenze der Laufzeit: Eine Funktion darf nicht länger als eine festgelegte Zeit laufen. Lange Aufgaben müssen Sie daher in Teile zerlegen.
• Zustandslosigkeit: Die Umgebung kann jederzeit verschwinden, daher dürfen Sie dauerhafte Daten nicht in der Funktion halten. Schreiben Sie Daten in einen externen Speicher.
• Zahl der Verbindungen: Viele gleichzeitige Funktionen können eine Datenbank mit Verbindungen überlasten.
• Beobachtbarkeit: Bei verstreuten Funktionen brauchen Sie gute Protokolle und Ablaufverfolgung, um Fehler zu finden.
• Wiederholungen: Viele Auslöser versuchen es bei Fehlern erneut. Wenden Sie das Prinzip der Idempotenz an, damit dieselbe Arbeit nicht doppelt läuft.
• Lokale Entwicklung: Die Cloud Umgebung lokal nachzubilden, kann schwierig sein.

Dennoch ist keine dieser Grenzen ein Ausschlussgrund. Jede verlangt jedoch eine Entwurfsentscheidung. Eine Dateiaufgabe, die an die Zeitgrenze stößt, teilen Sie zum Beispiel in kleine Teile und verbinden sie über eine Warteschlange. Dann bleibt jeder Teil innerhalb der Grenze, und nur der gescheiterte Teil läuft erneut.

Worauf achten Sie bei der Sicherheit von Serverless?

Der Anbieter schützt zwar die Infrastruktur, aber die Sicherheit der Anwendung bleibt bei Ihnen. Dieses Modell geteilter Verantwortung gilt auch für Serverless.

• Geringste Rechte: Geben Sie jeder Funktion nur die Berechtigungen, die sie braucht. Denn eine breite Rolle vergrößert einen möglichen Schaden.
• Geheimnisse: Schreiben Sie Passwörter und Schlüssel nicht in den Code. Nutzen Sie den Geheimnisdienst des Anbieters.
• Eingabeprüfung: Behandeln Sie jedes externe Datum als unvertrauenswürdig und prüfen Sie es.
• Abhängigkeiten: Halten Sie Bibliotheken aktuell, denn jede Funktion bringt ihr eigenes Paket mit.
• Kostenangriffe: Eine Funktion, die unbegrenzt skaliert, kann Ihre Rechnung bei feindlichem Verkehr aufblähen. Setzen Sie Ratenbegrenzungen und Budgetwarnungen.

Diese Liste ersetzt allerdings kein vollständiges Sicherheitsaudit. Lesen Sie vor dem Livegang die Sicherheitshinweise des Anbieters. Prüfen Sie außerdem in regelmäßigen Abständen, auf welche Ressourcen Ihre Funktionen zugreifen können, denn überflüssige Rechte sammeln sich mit der Zeit an.

Wie überwachen und testen Sie eine Serverless Anwendung?

Ein Problem in verstreuten Funktionen zu finden, ist schwerer als auf einem einzelnen Server. Richten Sie die Überwachung deshalb von Anfang an ein.

Sammeln Sie zunächst die Protokolle jeder Funktion an einem zentralen Ort. Danach verfolgen Sie Startzeit, Fehlerquote und Laufzeit getrennt. Anbieter stellen oft ein eigenes Protokollfeld für Cold Starts bereit. So erkennen Sie, ob eine Verlangsamung vom Start oder von Ihrem Code kommt.

Beim Testen funktionieren drei Ebenen gut:

1. Prüfen Sie die Geschäftslogik mit einfachen Einheitstests ohne Cloud.
2. Führen Sie die Funktion im lokalen Emulator des Anbieters oder in einer kleinen Testumgebung aus.
3. Messen Sie Cold Start und Skalierung unter einer Last, die dem echten Verkehr nahekommt.

Überspringen Sie jedoch den letzten Schritt nicht. Ein Cold Start zeigt sich nur in einer echten Cloud Umgebung, im lokalen Test nie. Beantworten Sie die Frage, was ist Serverless für Ihren Fall, deshalb mit Messung im Betrieb und nicht allein mit Code.

Wie arbeiten Serverless und Event Driven Architecture zusammen?

Die meisten Serverless Funktionen reagieren auf ein Ereignis. Darum sind Serverless und ereignisgesteuerter Entwurf also natürliche Partner. Ein Ereignis landet in einer Warteschlange oder einem Thema, die Funktion greift es auf und bearbeitet es.

Der Nutzen ist lose Kopplung. Der Erzeuger muss somit nicht wissen, wer das Ereignis verarbeitet. Um einen neuen Verbraucher hinzuzufügen, ändern Sie den bestehenden Teil nicht.

Es gibt aber auch einen Preis, und zwar den Mehraufwand. Ereignisse können außer der Reihe eintreffen, manche kommen doppelt an. Schreiben Sie Ihre Funktionen deshalb so, dass sie Wiederholungen vertragen.

Die Einzelheiten zu Ereignissen, Warteschlangen und Themen sprengen diesen Beitrag. Dafür lesen Sie Was ist Event Driven Architecture. Hier halten wir nur fest: Serverless ist ein Ausführungsmodell und kein Architekturmuster. Der ereignisgesteuerte Entwurf ist das Muster, in dem es sich am wohlsten fühlt.

Wie entscheiden Sie zwischen Serverless, Microservices und Monolith?

Diese drei Begriffe beantworten verschiedene Fragen. Monolith und Microservices betreffen die Aufteilung des Codes. Serverless betrifft, wo und wie Sie ihn ausführen. Das eine ist also keine Alternative zum anderen.

Für ein kleines Produkt ist eine einzelne Anwendung oft die einfachste Antwort. Sie können sie auf einem festen Server oder in einem Container betreiben. Später lagern Sie nur die Teile mit schwankender Last in Serverless Funktionen aus.

Am Anfang wirkt es verlockend, alles in Funktionen zu zerlegen. Viele winzige Funktionen erschweren jedoch Überwachung und Versionsverwaltung. Wählen Sie deshalb zunächst unabhängige Teile mit klaren Grenzen. Der Versand von Benachrichtigungen und die Bildverarbeitung sind zum Beispiel zwei Teile, die sich in den meisten Produkten von selbst abtrennen.

Dann hilft eine einfache Regel. Unterscheidet sich ein Teil bei Last, Latenz oder Größe deutlich vom Rest, trennen Sie ihn ab. Sonst erzeugt die Aufteilung nur Komplexität.

Welche Missverständnisse über Serverless sind verbreitet?

Wer dem Thema zum ersten Mal begegnet, tappt oft in dieselben Fallen. Wer sie früh korrigiert, vermeidet daher falsche Erwartungen.

• "Keine Server bedeuten keine Verwaltung." Den Server betreiben Sie nicht, aber Konfiguration, Berechtigungen und Überwachung bleiben bei Ihnen.
• "Es ist immer günstiger." Bei stoßweiser Last ist es günstiger. Bei gleichmäßig hoher Last muss das nicht gelten.
• "Cold Starts lassen sich nicht beheben." Sie können sie verringern, manche Methoden kosten aber extra.
• "Es passt zu jeder Anwendung." Lange Aufgaben und zustandsbehaftete Verbindungen passen schlecht.
• "Ein Umzug ist leicht." Der Code zieht um, die Dienste drumherum nicht.

Diese Missverständnisse haben dieselbe Quelle: kurze Werbetexte, die nur die gute Seite zeigen. Für eine solide Entscheidung müssen Sie Nutzen und Grenze kennen.

Wie könnte eine kleine Firmenwebsite Serverless nutzen?

Das ist ein Beispielszenario und kein echter Kundenfall. Stellen Sie sich einen lokalen Betrieb mit einer Firmenwebsite vor. Er möchte, dass Nachrichten aus dem Kontaktformular per E-Mail im Postfach landen.

Zunächst besteht die Seite aus statischen Dateien. Wird das Formular abgeschickt, startet eine Serverless Funktion, prüft die Daten und leitet die Nachricht weiter. Folglich mieten Sie für das Formular keinen eigenen Server. Bei wenig Verkehr bleiben somit auch die Kosten niedrig.

Will dieselbe Seite hochgeladene Bilder verkleinern, kann sie diese Aufgabe an eine Ereignisfunktion geben. Für schwere Berechnungen können Sie außerdem Techniken wie WebAssembly nutzen.

Bevor Sie jedoch die gesamte Seitenerzeugung an Serverless binden, messen Sie den Einfluss des Cold Starts. Welches CMS Ihre eigene Seite nutzt, sehen Sie mit unserem CMS Checker.

Welche Checkliste gehen Sie vor dem Wechsel zu Serverless durch?

Beantworten Sie diese Fragen der Reihe nach, bevor Sie entscheiden. Jede Antwort bringt Sie also der richtigen Wahl näher.

1. Ist die Last ereignisgesteuert und unregelmäßig oder dauerhaft?
2. Ist eine Cold Start Verzögerung auf dem Pfad, auf den der Nutzer wartet, vertretbar?
3. Bleibt die Laufzeit jeder Funktion innerhalb der Grenze des Anbieters?
4. Halten Sie dauerhafte Daten in einem externen Speicher?
5. Sind Ihre Vorgänge gegen Wiederholungen idempotent?
6. Sind Fehlerverfolgung und Protokollierung bereit?
7. Existiert eine Schicht, die die Anbieterbindung senkt?
8. Stehen aktuelle Preise, Grenzen und kostenlose Kontingente auf der offiziellen Seite fest?
9. Zeigt eine Messung den Cold Start unter einer Last, die dem echten Verkehr ähnelt?

Sind zwei oder drei Punkte unklar, dann starten Sie mit einem kleinen Pilotprojekt. Verschieben Sie eine Funktion, messen Sie und entscheiden Sie dann.

Wenn Sie bei Fragen der Softwarearchitektur Unterstützung wünschen, schauen Sie sich unsere Seite zur individuellen Softwareentwicklung an.

Was ist Serverless kurz gesagt, und welche offiziellen Quellen helfen?

Kurz zusammengefasst: Serverless überlässt die Verwaltung der Infrastruktur dem Anbieter und führt Code pro Ereignis aus. Der Cold Start ist die Vorbereitungsverzögerung dieses Modells. Warme Instanzen, kleine Pakete und schlanker Startcode verringern sie.

Konkret verkürzen Edge Functions die Entfernung, warme Instanzen die Verzögerung und Messungen die Unsicherheit. Dennoch hat jedes Werkzeug seinen Preis. Das tatsächliche Verhalten Ihrer Last bestimmt also das Gleichgewicht.

Für Details lesen Sie die offizielle Dokumentation der Anbieter. Die AWS Seite zum Lebenszyklus der Lambda Ausführungsumgebung erklärt Cold Starts und warme Umgebungen. Die Seite von Microsoft zu den Hosting Optionen von Azure Functions vergleicht Tarife und das Verhalten beim Cold Start. Das Dokument von Google zu Mindestinstanzen in Cloud Run beschreibt den Ansatz mit warmen Instanzen.

Dieser Beitrag ist keine Beratung zu Architektur, Recht oder Finanzen. Grenzen und Preise ändern sich mit der Zeit.