EMZETT.SaaS
Kurz: “Software as a Service” — Software, die man als Abo über den Browser nutzt, statt sie zu kaufen und lokal zu installieren (z. B. Stripe, Vercel, Resend selbst sind SaaS-Produkte).
Genauer: Beim SaaS-Modell betreibt der Anbieter Server, Updates und Wartung zentral, Kunden zahlen meist ein laufendes Abo statt einer Einmallizenz. Für Entwickler heißt das: Integration meist über eine API/ein Dashboard, keine eigene Serververwaltung nötig — Grundprinzip fast aller in diesem Wiki dokumentierten Drittanbieter-Services.
Im Detail
SaaS ist eines von mehreren “As-a-Service”-Cloud-Modellen, die sich darin unterscheiden, wie viel der Anbieter übernimmt und wie viel Kontrolle beim Kunden bleibt: IaaS (Infrastructure as a Service, z. B. rohe virtuelle Server) gibt volle Kontrolle über das Betriebssystem, erfordert aber eigene Wartung; PaaS (Platform as a Service, z. B. Vercel) übernimmt Infrastruktur und Betriebssystem, der Kunde liefert nur noch seinen Anwendungscode; SaaS geht am weitesten — der Kunde nutzt eine fertige Anwendung über Browser/API, ohne sich um irgendeine darunterliegende Technik zu kümmern.
Für Entwickler bedeutet die Integration von SaaS-Diensten meist: ein API-Key besorgen, gegen eine dokumentierte API entwickeln, Webhooks für asynchrone Ereignisse (z. B. eine erfolgreiche Zahlung) einrichten. Der große Vorteil ist Geschwindigkeit — statt Zahlungsabwicklung, E-Mail-Versand oder Authentifizierung von Grund auf selbst zu bauen, integriert man einen spezialisierten Anbieter, der genau dieses eine Problem professionell löst. Der Kompromiss: Abhängigkeit von einem externen Anbieter (Preisänderungen, Ausfälle, Abkündigung des Dienstes liegen außerhalb der eigenen Kontrolle).
Multi-Tenancy als technisches Fundament
Fast jedes SaaS-Produkt basiert auf “Multi-Tenancy” — eine einzige Anwendungsinstanz bedient viele Kunden (“Mandanten”) gleichzeitig, deren Daten strikt voneinander isoliert bleiben müssen, obwohl sie dieselbe zugrunde liegende Infrastruktur teilen. Das erlaubt dem Anbieter, Kosten über viele Kunden zu verteilen (ein Server-Cluster statt einer Installation pro Kunde), erfordert aber sorgfältiges Design, damit z. B. eine Datenbankabfrage niemals versehentlich Daten eines anderen Mandanten zurückliefert — ein Fehler in der Mandantentrennung zählt zu den schwerwiegendsten möglichen Sicherheitslücken in SaaS-Architekturen.
Preismodelle
SaaS-Anbieter nutzen meist wiederkehrende Abrechnungsmodelle statt einer Einmalzahlung: nutzungsbasiert (pro versendeter E-Mail, pro API-Aufruf — passend für unregelmäßige Last), Staffelpreise nach Nutzerzahl/Funktionsumfang (“Tiers”, z. B. Free/Pro/Enterprise), oder Flatrates mit Obergrenzen. Diese Modelle erlauben es kleinen Projekten, mit geringen laufenden Kosten zu starten und erst bei tatsächlichem Wachstum mehr zu zahlen — ein deutlicher Unterschied zu früheren Software-Lizenzmodellen, die oft hohe Vorabinvestitionen erforderten, unabhängig von der tatsächlichen Nutzung.
Vendor Lock-in als Risiko
Der zentrale langfristige Nachteil von SaaS ist “Vendor Lock-in” — je tiefer ein SaaS-Dienst in die eigene Anwendung integriert ist (proprietäre APIs, dienstspezifische Datenformate, fest verdrahtete Workflows), desto aufwändiger wird ein späterer Wechsel zu einem anderen Anbieter oder einer selbst gehosteten Alternative. Erfahrene Teams begrenzen dieses Risiko durch Abstraktionsschichten (z. B. eine eigene Zahlungsschnittstelle, hinter der sich austauschbar Stripe oder ein anderer Anbieter verbergen könnte) oder bewusste Wahl von Diensten mit Standard-Exportformaten für die eigenen Daten.