SaaS (Software as a Service)

SaaS hat die IT-Welt erobert. Vorteile für dich:

• Zugriff überall: Du kannst deine E-Mails (Gmail) am PC, am Handy oder im Internetcafé lesen.
• Keine Wartung: Du musst keine Updates installieren oder Backups machen (macht Google/Microsoft für dich).
• Skalierbar: Wenn deine Firma wächst, buchst du einfach 5 neue User dazu (Klick im Admin-Bereich).

Nachteil:

• Du besitzt nichts. Abo kündigen = Daten weg (oder nur noch Lesezugriff).
• Ohne Internet geht oft nichts.

1. Multi-Tenancy (Mandantenfähigkeit)

SaaS-Anbieter betreiben oft eine riesige Instanz für alle Kunden. Deine Daten liegen in derselben Datenbank wie die von Coca-Cola. Die Software muss Multi-Tenant sicher sein: Ein logischer Riegel sorgt dafür, dass Kunde A niemals die Daten von Kunde B sieht, obwohl sie auf demselben Server liegen.

2. Lock-in Effekt

SaaS-Anbieter machen es leicht, reinzukommen, aber schwer, rauszugehen. Datenexport ist oft kompliziert. Wenn du dein ganzes Firmenwissen in Salesforce hast, ist ein Wechsel zu einem anderen Tool extrem teuer und schmerzhaft ("Vendor Lock-in").

1. Multi-Tenancy Architecture Patterns

"Derselbe Server, viele Kunden." Wie funktioniert das tief im Datenbank-Layer?

1. Silo-Modell (Single Tenant): Jeder Kunde bekommt dediziert eine eigene DB (db_coca_cola, db_pepsi). Extrem teuer in der Verwaltung (100 DBs patchen), exzellente Isolation (Compliance). Keine "echte" SaaS Skalierung.
2. Pool-Modell (True Multi-Tenant): Es gibt nur eine einzige Giga-Tabelle Users. Jeder Row hat einen foreign key tenant_id. Absolute Hardware-Effizienz, aber höchstes Risiko: Fehler in einem SQL-Query (forgotten WHERE tenant_id = 7) führt zum Cross-Tenant Data Leak (Kunde sieht Daten vom Konkurrenten). Moderne ORMs nutzen Row-Level Security (RLS) im Postgres-Kernel, um den User-Programmierer physisch daran zu hindern, die falsche Tenant_ID abzugreifen.

2. Service Level Objectives (SLOs) und Noisy Neighbors

Im Pool-Modell teilt sich StartUpX denselben Web-Server wie Coca-Cola. Wenn Coca-Cola am BlackFriday eine Million Anfragen sendet, stiehlt es den CPU-Timeslice. Die Requests von StartUpX erhalten plötzlich Timeouts. Das ist das Noisy Neighbor API Problem. Plattform Engineers von SaaS Firmen steuern rigoros mit Rate-Limiting, Fair-Queueing und cgroup-Slices gegen. Da SLA-Strafzahlungen bei Vertragsverletzungen fließen, etablieren SREs (Site Reliability Engineers) Fehler-Budgets (SLO). Ein Ausfall ist "erlaubt", sofern 99,99% (4 Nines) Uptime im Monat gerettet werden (das sind max. 4,32 Minuten Downtime pro Monat). Ist das Budget verbraucht, erteilt das Ops-Tier gnadenlosen Production-Freeze auf neue Features.

3. SSO, SCIM und Enterprise-Onboarding

Wie verkauft man eine SaaS an eine 100.000-Mitarbeiter Bank? Du kannst nicht 100.000 Accounts manuell via Excel eintippen. Das Enterprise-Level erzwingt SSO (Single Sign-On) via SAML/OIDC. Die Bank sagt: "Unsere Mitarbeiter loggen sich nur über unser Azure AD ein, deine SaaS muss das tokenbasiert per Vertrauen abnicken." Wenn der Bank-Mitarbeiter kündigt, loggt der Bank-Admin ihn im Azure AD aus. Wie merkt die SaaS (z.B. Slack) das, um die Lizenzgebühr zu stoppen? SCIM (System for Cross-domain Identity Management). Das AD ruft per REST-API automatisch den Webhook bei Slack auf (DELETE /users/max.mustermann) und vollzieht das De-Provisioning in Nanosekunden ("Joiner-Mover-Leaver" Prozess), ohne dass Menschen eingreifen. Ohne SCIM-Support kein Enterprise-Vertrag.