Cloud-Native, IaaS, PaaS und SaaS einfach erklärt

Cloud ist kein Ort am Himmel. Es ist die Frage, wie viel von der Maschine du selbst betreibst und wie viel jemand anders.

Ich arbeite als Software-Unternehmer an der Schnittstelle von Product, GTM und AI. Sobald AI-Agents in deinem Produkt-Team mitlaufen, ist diese Frage keine Theorie mehr. Sie entscheidet, wo deine Agents arbeiten und wie schnell.

Was du hier mitnimmst:

• Was IaaS, PaaS und SaaS konkret bedeuten, in einem Satz pro Schicht.
• Warum die Grenzen dazwischen längst verschwimmen.
• Warum die Cloud-Architektur zählt, wenn Agents bei dir laufen.

Meine These: Die drei Modelle sind drei Schichten desselben Stapels. Du musst nur wissen, welche du selbst betreibst.

🧨 Drei Schichten, ein Stapel

Die offizielle Definition kommt vom NIST. Im Alltag reichen drei einfache Sätze.

IaaS, Infrastructure as a Service. Die unterste Schicht. Du mietest nur die Hardware: Rechenleistung, Speicher, Netzwerk, virtualisiert in einem Rechenzentrum. Betriebssystem und alles darüber installierst du selbst. Du mietest IT-Infrastruktur und Wartung, sonst nichts.

PaaS, Platform as a Service. Die mittlere Schicht. Hier ist nicht der IT-Administrator gefragt, sondern der Entwickler. Der Anbieter stellt die Umgebung als Framework bereit und gibt Programmiersprachen, Schnittstellen und Datenspeicher vor. Du kontrollierst nur deinen eigenen Code und deine Daten, nicht die Infrastruktur darunter.

SaaS, Software as a Service. Die oberste Schicht, sie baut auf den beiden anderen auf. Du kaufst die Software nicht und installierst sie nicht. Du mietest sie als Dienst. Meist reichen ein internetfähiges Gerät und ein Browser. Günstige Hardware bei dir, volle Rechenpower im Rechenzentrum.

Ein Alltagsbild hilft. IaaS ist der Rohbau: du mietest die Wände und baust alles selbst aus. PaaS ist die eingerichtete Werkstatt: du bringst nur dein eigenes Projekt mit. SaaS ist das fertige Gerät im Abo: einschalten und benutzen.

🛠️ Warum die Grenzen verschwimmen

Die saubere Schichttorte ist Theorie. In der Praxis verwischen die Linien seit Jahren. Schon bevor Azure 2012 virtuelle Maschinen anbot, war oft nicht mehr klar, wo IaaS aufhört und PaaS anfängt.

Echte Projekte fragen nicht nach dem Modell. Sie bündeln Fähigkeiten: eine API hier, eine Komponente dort, ein Service obendrauf. Es ist nicht IaaS oder PaaS. Es ist IaaS und PaaS und SaaS, oft im selben Projekt. Dazu kommt der Hybrid-Ansatz, der sogar die Grenze zur eigenen Hardware vor Ort verwischt.

Anfangs musste man PaaS noch erklären und rechtfertigen. Schnell ging es nur noch um echte Entwicklungsprojekte. Die Reife rund um Hybrid-Cloud wuchs Jahr für Jahr. Das ist der Stand heute: nicht ein Modell, sondern ein Mix, den du bewusst zusammenstellst.

Dazu kommt: ganze Produktkategorien liegen heute zwischen den Schichten. Verwaltete Datenbanken, Container-Dienste, Serverless-Funktionen. Alles Mischformen, bei denen der Anbieter mehr übernimmt als bei roher Infrastruktur und weniger vorgibt als eine volle Plattform. Das Schichtenmodell bleibt trotzdem nützlich. Es beantwortet die einzige Frage, die zählt: wer betreibt was.

🧭 Der Entscheidungsweg: eine Firma, drei Antworten

Nimm eine B2B-Software-Firma mit 30 Leuten. Ein Produkt, ein kleines Team, keine eigene Ops-Abteilung. An ihr lässt sich die Wahl durchspielen, Schicht für Schicht.

Rohe Infrastruktur ergibt Sinn, wenn du Kontrolle wirklich brauchst. Etwa wenn Kunden vertraglich vorschreiben, wo Daten liegen und wer Zugriff hat. Oder wenn dein Produkt Anforderungen an Laufzeit oder Hardware stellt, die Standard-Plattformen nicht abdecken. Dann mietest du Maschinen und betreibst den Rest selbst. Der Preis: du brauchst Leute, die das können und wollen. In der 30-Personen-Firma heisst das schnell, dass sich 2 davon nur noch um Infrastruktur kümmern.

Eine Plattform ergibt Sinn, wenn dein Engpass Entwicklung ist, nicht Betrieb. Für unsere Firma ist das der Normalfall. Das Team schreibt Code, die Plattform übernimmt Server, Skalierung und Patches darunter. Du gibst Kontrolle ab und bekommst Tempo zurück. Für ein Produkt-Team ohne eigene Ops ist das fast immer der richtige Ausgangspunkt.

Fertige Software ergibt Sinn für alles, was dich nicht unterscheidet. Mail, CRM, also das System für die Kundendaten, Buchhaltung, Support-Tool: mieten, nicht bauen. Die Firma gewinnt keinen einzigen Kunden, weil sie ihr Ticketing selbst betreibt. Jede Stunde dort ist eine Stunde weniger am eigenen Produkt.

Der Entscheidungsweg ist also keine Glaubensfrage. Er ist eine Frage pro System: unterscheidet uns das? Wenn nein, kauf so weit oben im Stapel wie möglich. Wenn ja, nimm so viel Kontrolle wie nötig und so wenig Eigenbetrieb wie möglich.

Für die 30-Personen-Firma sieht das Ergebnis oft so aus: das eigene Produkt auf einer Plattform, die Datenbank als verwalteter Dienst, ein Stück rohe Infrastruktur für den einen Kunden mit Sonderauflagen, drumherum ein Dutzend gemietete Werkzeuge. Genau der Mix aus dem Abschnitt davor. Kein Reinheitsgebot, sondern eine Reihe bewusster Einzelentscheide.

⚖️ Drei Trade-offs, in Klartext

Hinter jeder Schichtwahl stecken dieselben 3 Abwägungen. Wer sie kennt, kann jede Anbieter-Folie in Minuten einordnen.

Kontrolle gegen Verantwortung. Jede Schicht, die du selbst betreibst, gehorcht dir. Und sie ruft dich an, wenn sie nachts ausfällt. Kontrolle klingt nach Freiheit, gemeint ist Pikettdienst. Die ehrliche Frage lautet nicht "wollen wir Kontrolle", sondern "wollen wir die Verantwortung, die daran hängt".

Lock-in gegen Geschwindigkeit. Je mehr fertige Dienste du nutzt, desto schneller lieferst du. Und desto tiefer wächst du in einen Anbieter hinein. Ein Wechsel wird teuer, nicht unmöglich. Der Fehler ist nicht der Lock-in an sich. Der Fehler ist, ihn unbewusst einzugehen. Wer aus Angst vor Lock-in alles selbst baut, zahlt den Preis sofort statt vielleicht später.

Fixkosten gegen Nutzungskosten. Eigenbetrieb kostet, ob jemand dein Produkt nutzt oder nicht. Nutzungsbasierte Dienste kosten wenig bei wenig Last und wachsen mit dem Erfolg mit. Für ein junges Produkt ist das zweite meist besser. Du zahlst erst viel, wenn du Kunden hast. Dafür brauchst du ein Auge auf der Rechnung, denn Nutzungskosten wachsen leise.

Wichtig ist die Reihenfolge: erst entscheiden, was dich unterscheidet, dann die Trade-offs pro System abwägen. Wer es umgekehrt macht, diskutiert Wochen über Anbieter und hat am Ende trotzdem keine Linie.

🤖 Warum das im Agenten-Zeitalter zählt

Genau hier wird es für mich konkret. Ich baue AI-native Produkt-Teams. Ich nenne das Get Multiplayer: wie Menschen und AI-Agents zusammen arbeiten. Ein Hyperlean-Team, ein paar Profis plus Agents, die rund um die Uhr laufen. Drei statt dreissig.

Diese Agents laufen irgendwo. Ob auf IaaS, PaaS oder als SaaS angebunden, entscheidet über Latenz, Kosten und Datenkontrolle. Wer seinen Code, sein Jira und seine Daten in der EU halten muss, für den ist die Schichtwahl keine Technikfrage, sondern eine Compliance-Frage.

Für DACH-Firmen ist das keine Randnotiz. Viele B2B-Kunden verlangen im Vertrag, dass Daten in der EU oder in der Schweiz bleiben. Das ist der Normalfall, nicht die Ausnahme. Alle 3 Schichten gibt es mit europäischen Regionen. Du musst es nur bei der Auswahl prüfen statt nachträglich reparieren.

Dazu kommt der Kontext. Ein Agent ist nur so gut wie seine Grundlage. Diese Grundlage ist die Context Engine: der Business- und Code-Kontext deiner Firma. Wo dieser Kontext liegt und wie die Agents drankommen, das ist eine Frage der Cloud-Architektur. Ohne sauberen Kontext ist es Garbage in, Garbage out.

🧑‍💻 Was heisst das für ein kleines Produkt-Team?

Kauf alles, was dich nicht unterscheidet, als fertigen Dienst. Betreib so wenig wie möglich selbst. Und entscheide die Schichtfrage, bevor deine Agents laufen, nicht danach. Denn die Architektur bestimmt, auf was deine Agents zugreifen können und wie schnell.

Das knüpft an den Punkt oben an. Sobald AI-Helfer im Produkt mitarbeiten, wirkt jede Schichtentscheidung doppelt. Sie bestimmt, wo dein Code läuft. Und sie bestimmt, ob ein Agent an Logs, Daten und Deployments herankommt, ohne dass ein Mensch dazwischen klickt.

Ein kleines Team hat hier einen Vorteil: wenig Altlast. Du kannst die Architektur so schneiden, dass der Kontext an einem Ort liegt und die Agents dort arbeiten. Wie so ein Setup in der Praxis entsteht, zeige ich in SaaS-Produkt in 90 Tagen und in From Vibe Coding zu Agentic Engineering.

Die Schichtfrage ist damit Teil des Produktmanagements, nicht der IT. Mehr dazu sammle ich im Hub Software-Produktmanagement.

🎢 Highs, Lows, Warnung

✅ Was funktioniert: Die Schichten als mentales Modell. Frag bei jedem Dienst: Welche Schicht betreibe ich selbst, welche jemand anders. Das räumt die meiste Verwirrung weg.

❌ Was nicht funktioniert: Die Modelle als starre Schubladen behandeln. Die Realität ist gemischt, hybrid und verschwommen. Wer auf die saubere Torte wartet, plant an der Praxis vorbei.

⚠️ Warnung: Lass die Cloud-Architektur nicht zufällig entstehen. Sobald Agents bei dir laufen, bestimmt sie Tempo, Kosten und wo deine Daten liegen.

Cloud ist kein Ort am Himmel, sondern eine Entscheidung darüber, was du selbst betreibst. Im Agenten-Zeitalter wird diese Entscheidung wichtiger, nicht unwichtiger. Wenn du Agents in deinem Produkt-Team einsetzen willst, die deinen Kontext kennen, schau bei teklens.ai vorbei.