Software ArchitectureAtlas

Software Architecture Atlas

Überblick gewinnen. Zusammenhänge verstehen.

Eigenständiger BegriffBetriebsmodellKapitel III · Betrieb · Baustein 16 von 17

Serverless

Infrastrukturbetrieb bindet Teams auch dann, wenn Funktionen nur ereignisweise laufen.

Von Michael Meierhoff · Meierhoff Systems

  1. EreignisEreignis: Eingang startet eine abgegrenzte Ausführung.
  2. VerantwortungVerantwortung: Plattform betreibt Infrastruktur und Laufzeit.
  3. GrenzeGrenze: Laufzeit, Parallelität und Abhängigkeiten bleiben zu gestalten.

Einordnung

Warum das wichtig ist

Betrieb auf verwalteter Infrastruktur mit expliziten Grenzen gestalten.

Betrieb auf verwalteter Infrastruktur mit expliziten Grenzen gestalten.

Shop-Beispiel · Zuordnung

Serverless: Entscheidung prüfen

Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Eine hypothetische Erweiterung des Beispielshops sendet nach Bestellannahme ein Ereignis an eine serverless Rechnungsfunktion. Die Funktion erstellt den Beleg und speichert ihn in einem eigenen Ablagebereich; die bestehende gemeinsame Shop-Datenbank und ihre sieben Module bleiben unverändert. Ein Burst vieler Bestellungen kann parallele Funktionsstarts auslösen, daher begrenzt das Team die Parallelität und prüft Broker-Wiederholungen, Idempotenz, Laufzeitbudget und Kosten pro Rechnung.

So liest du das Bild

  1. Ereignis Ereignis
  2. Verantwortung Verantwortung
  3. Grenze Grenze
Serverless: Entscheidung prüfen
BegriffBedeutungPrüffrage
EreignisEingang startet eine abgegrenzte Ausführung.Wodurch wird die Rechnungsfunktion ausgelöst?
VerantwortungPlattform betreibt Infrastruktur und Laufzeit.Welche Laufzeitgrenze gehört in den Entwurf?
GrenzeLaufzeit, Parallelität und Abhängigkeiten bleiben zu gestalten.Welche Messwerte prüfen die Betriebseignung?
Serverless beschreibt ein Cloud-Betriebsmodell, in dem ein Anbieter Infrastruktur und Ausführungsumgebung verwaltet und Kapazität weitgehend bedarfsgesteuert bereitstellt. Teams konfigurieren Funktionen, Ereignisquellen und Dienste statt Serverinstanzen zu betreiben. Prüfe das Szenario mit den Fragen in der zweiten Spalte.

Nutzen & Grenzen

Hilft, wenn

  • Betrieb auf verwalteter Infrastruktur mit expliziten Grenzen gestalten.
  • Ereignisquellen, Laufzeitgrenzen und Abrechnung im Lastfall prüfen.

Grenzen

  • Anbietergrenzen und Laufzeitkosten verschieben den Betriebsaufwand.
  • Cold starts, maximale Ausführungsdauer und Anbieterbindung müssen zum Interaktions- und Betriebsmodell passen.

In der Praxis

  1. Zeichne den Weg vom Bestellereignis bis zum Beleg und kläre, wie der Trigger Wiederholungen, doppelte Zustellung und Schemaänderungen des Ereignisses behandelt.
  2. Teste eine Funktion oberhalb ihrer Laufzeitgrenze sowie den Ausfall des Ablagespeichers; prüfe Idempotenz, Retry-Verhalten und die Zuordnung eines Fehlers zur Bestellung.
  3. Berechne Kosten für normale und Spitzenlast einschließlich Aufrufen, Laufzeit und Speicherzugriff und vergleiche sie mit einer dauerhaft betriebenen Alternative.
Ausführliche Erklärung lesen

Serverless beschreibt ein Cloud-Betriebsmodell, in dem ein Anbieter Infrastruktur und Ausführungsumgebung verwaltet und Kapazität weitgehend bedarfsgesteuert bereitstellt. Teams konfigurieren Funktionen, Ereignisquellen und Dienste statt Serverinstanzen zu betreiben.

Architekturverantwortung bleibt bestehen: Laufzeitgrenzen, Kaltstarts, Parallelität, Berechtigungen, Beobachtbarkeit und Kosten bestimmen die Eignung. Serverless kann Funktionen und Datenbanken umfassen; es bedeutet weder serverfreie Ausführung noch automatisch ereignisbasierte Gestaltung.

Das Shop-Beispiel nutzt die bestehende gemeinsame Datenbank und sieben Module. Jede ergänzte Dienst- oder Betriebsform ist eine hypothetische Erweiterung. Eine hypothetische Erweiterung des Beispielshops sendet nach Bestellannahme ein Ereignis an eine serverless Rechnungsfunktion. Die Funktion erstellt den Beleg und speichert ihn in einem eigenen Ablagebereich; die bestehende gemeinsame Shop-Datenbank und ihre sieben Module bleiben unverändert. Ein Burst vieler Bestellungen kann parallele Funktionsstarts auslösen, daher begrenzt das Team die Parallelität und prüft Broker-Wiederholungen, Idempotenz, Laufzeitbudget und Kosten pro Rechnung. serverless und skalierung helfen, diese Entscheidung mit benachbarten Fragen zu vergleichen.

Selbst prüfen

Teste dich in drei Stufen

  1. AblesenIm Bild nachsehen

    Wodurch wird die Rechnungsfunktion ausgelöst?

    Lösung mit Begründung ansehen

    Ein Bestellereignis ruft die verwaltete Funktion auf.

  2. AnwendenAuf eine neue Lage übertragen

    Welche Laufzeitgrenze gehört in den Entwurf?

    Lösung mit Begründung ansehen

    Maximale Ausführungsdauer samt Retry- und Idempotenzverhalten.

  3. BewertenEine Alternative abwägen

    Welche Messwerte prüfen die Betriebseignung?

    Lösung mit Begründung ansehen

    Cold-start-Latenz, Ausführungsdauer, Ereignisfehler und Kosten pro Aufruf.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

BetriebDeployment & RolloutEinordnung und VergleichÖffnen BetriebSkalierungFachlicher ZusammenhangÖffnen

Quellen

Weiter im Lernpfad

Als Nächstes in Laufzeit & Betrieb: Wiederherstellung.

17 Bausteine

Weiter mitWiederherstellung