IaaS PaaS SaaS Unterschied: Cloud Servicemodelle erklärt

Was ist der IaaS PaaS SaaS Unterschied?

IaaS, PaaS und SaaS sind die drei Cloud Servicemodelle und beschreiben, wie viel eines Cloud Dienstes der Anbieter betreibt und wie viel Sie selbst übernehmen. IaaS vermietet Infrastruktur wie virtuelle Server, PaaS liefert eine fertige Plattform für Ihren Code, und SaaS stellt fertige Software bereit, die Sie im Browser nutzen.

Kurz gesagt verraten die drei Kürzel, wer in der Küche arbeitet. Mieten Sie die Infrastruktur, sind Sie bei IaaS. Übergeben Sie Ihren Code an eine fertige Plattform, nutzen Sie PaaS. Abonnieren Sie eine fertige Anwendung, nutzen Sie SaaS. Deshalb beeinflusst die Wahl Ihr Budget, Ihre Sicherheitspflichten und die Arbeitslast Ihres Teams.

Dieser Leitfaden widmet sich einem einzigen Begriff und erklärt den IaaS PaaS SaaS Unterschied vom Einstieg bis ins technische Detail. Benachbarte Themen streifen wir nur kurz. Unsere Artikel darüber, was eine API ist, und darüber, was DevOps bedeutet, behandeln zum Beispiel Konzepte, die auf diesen Modellen aufbauen.

Wie erklärt die Pizza Analogie den IaaS PaaS SaaS Unterschied?

Das Pizza Beispiel macht die drei Modelle in etwa einer Minute greifbar. Backen Sie zu Hause, gehören Ihnen Ofen, Zutaten, Teig und Tisch. Das entspricht der eigenen Infrastruktur (englisch On Premises). Die anderen drei Optionen unterscheiden sich dann darin, wie viel Arbeit Sie abgeben.

• Zu Hause backen (eigene Infrastruktur): Sie kaufen alles, backen selbst und räumen auf. Sie haben volle Kontrolle, tragen aber auch die volle Arbeitslast.
• Küche mieten (IaaS): Ofen und Arbeitsplatte sind vorhanden. Zutaten, Rezept und Backen bringen Sie selbst mit.
• Fertigen Teig kaufen (PaaS): Teig und Ofen sind bereit. Sie entscheiden also nur noch über den Belag.
• Pizza bestellen (SaaS): Die Pizza kommt fertig auf den Tisch. Allerdings können Sie das Rezept nicht ändern.

Die Analogie hat allerdings eine Grenze. Bei echter Software sind Ihre Daten das "Rezept", und die Verantwortung dafür bleibt in jedem Modell bei Ihnen. Die Tabelle weiter unten zeigt das im Detail.

Was ist Cloud Computing laut NIST?

Cloud Computing ist ein Modell, das bei minimalem Aufwand einen bedarfsgerechten Netzwerkzugriff auf einen gemeinsamen Pool konfigurierbarer Rechenressourcen ermöglicht. Diese Definition stammt vom US Institut für Standards und Technologie (NIST) und steht in der NIST Definition von Cloud Computing, einer der meistzitierten Quellen der Branche.

NIST beschreibt die Cloud mit fünf wesentlichen Merkmalen:

• Selbstbedienung bei Bedarf: Sie richten Ressourcen selbst ein, ohne mit dem Anbieter zu sprechen.
• Breiter Netzwerkzugriff: Sie erreichen den Dienst von Smartphone, Laptop und anderen Geräten.
• Ressourcenbündelung: Der Anbieter teilt dieselbe Hardware auf viele Kunden auf.
• Schnelle Elastizität: Sie vergrößern oder verkleinern Ressourcen, sobald sich Ihr Bedarf ändert.
• Gemessene Dienste: Die Nutzung wird gemessen, daher zahlen Sie nur für das, was Sie verbrauchen.

Dasselbe Dokument unterscheidet drei Servicemodelle (SaaS, PaaS und IaaS) und vier Bereitstellungsmodelle (private, gemeinschaftliche, öffentliche und hybride Cloud). Dieser Artikel konzentriert sich auf die Servicemodelle, denn die Bereitstellungsmodelle beschreiben, wem die Cloud gehört.

Was ist IaaS und was umfasst es?

IaaS steht für Infrastructure as a Service und lässt Sie grundlegende Rechenressourcen wie virtuelle Maschinen, Speicher und Netzwerk mieten. Laut NIST verwalten Sie die physische Infrastruktur nicht. Stattdessen kontrollieren Sie Betriebssystem, Speicher und die Anwendungen, die Sie darauf einrichten.

In der Praxis kümmert sich der Anbieter um Rechenzentrum, Strom und Netzwerkhardware. Sie pflegen Betriebssystem Updates, Sicherheitspatches, Firewall Regeln und Backups. Folglich bietet IaaS die größte Flexibilität, bringt aber auch die höchste Betriebslast der drei Cloud Modelle mit.

IaaS ist sinnvoll, wenn Sie eine ältere Anwendung unverändert in die Cloud verlegen, ein ungewöhnliches Betriebssystem einsetzen oder Ihre Ressourcen fein abstimmen möchten. Auch ein VPS (virtueller privater Server) ist im Kern IaaS. Wie sich die Optionen unterscheiden, lesen Sie in unserem Vergleich VPS oder Cloud Server und VDS.

Ein typisches IaaS Paket enthält diese Bausteine:

• Virtuelle Maschinen: Server, bei denen Sie Prozessor und Arbeitsspeicher wählen und das Betriebssystem selbst einrichten.
• Speicher: Festplatten, Objektspeicher und Platz für Backups Ihrer Daten.
• Netzwerk: Virtuelle Netze, Firewall Regeln und Lastverteiler, die den Datenverkehr lenken.

Diese Bausteine setzen Sie selbst zusammen und stimmen sie ab. Anders gesagt mietet IaaS eine leere Büroetage, und Schreibtische, Internet und Aufteilung richten Sie selbst ein.

Was ist PaaS und was gewinnen Entwickler dadurch?

PaaS steht für Platform as a Service und liefert eine fertige Umgebung, in der Ihre Anwendung läuft. Laufzeitumgebung, Datenbankanbindung, automatische Skalierung und eine Bereitstellungspipeline sind im Paket enthalten. Nach NIST laden Sie Ihre eigene oder zugekaufte Anwendung dort hoch und verwalten weder Server noch Netzwerk noch Betriebssystem darunter.

Der Gewinn liegt auf der Hand, denn Server patchen, Skalierung einstellen und Betriebssystemversionen verfolgen fallen größtenteils weg. Ihr Team investiert die Zeit stattdessen ins Produkt. Vor allem kleine Teams spüren den Unterschied schnell in der Wochenarbeit.

Den Preis zahlen Sie bei der Flexibilität, weil Sie mit den Sprachen, Versionen und Datenbanktypen, die die Plattform unterstützt. Außerdem wird ein Umzug schwerer, wenn Sie stark auf plattformspezifische Funktionen setzen. Deshalb verpacken viele Teams ihre Anwendungen als Container, also als portable Pakete samt Abhängigkeiten. Unser Leitfaden Was ist Docker erklärt die Idee.

Ein typisches PaaS Paket enthält diese Bausteine:

• Laufzeitumgebung: Eine gepflegte Umgebung für die gewählte Programmiersprache.
• Bereitstellungspipeline: Ein Ablauf, der Ihre Anwendung dann automatisch veröffentlicht, sobald Sie den Code verbinden.
• Verwaltete Dienste: Fertige Bausteine wie Datenbanken, Zwischenspeicher und Warteschlangen.
• Skalierung und Überwachung: Werkzeuge, die bei mehr Verkehr Kapazität ergänzen und zudem den Zustand zeigen.

PaaS ist somit die natürliche Wahl für Teams, die sagen: "Wir wollen uns nur um unseren Code kümmern."

Was ist SaaS und warum ist es das häufigste Modell?

SaaS steht für Software as a Service und bedeutet, dass Sie eine fertige Anwendung per Abonnement über Browser oder Mobile App nutzen. Zum Beispiel gehören E-Mail und Kalender, Büroanwendungen, Kundenverwaltung (CRM), Projektplanung und Onlineshop Plattformen dazu.

In diesem Modell betreibt der Anbieter alles, von der Infrastruktur bis zu den Anwendungsupdates. Sie verwalten dagegen Konten, Benutzerrechte, Einstellungen und die Daten, die Sie eintragen. Sie können also am selben Tag starten, denn eine Installation entfällt.

SaaS ist das häufigste Modell, weil die meisten Unternehmen ihr Geschäft führen und keine Software schreiben wollen. Allerdings hat es eine Grenze: Anpassungen gehen nur so weit, wie der Anbieter sie erlaubt. Daher sollte ein gutes SaaS Produkt eine API anbieten, den Datenexport erlauben und sich mit Ihren anderen Systemen verbinden.

Die meisten SaaS Produkte arbeiten mandantenfähig (englisch Multi Tenant). Das heißt, dieselbe Software Instanz bedient viele Kunden, während Ihre Daten logisch getrennt bleiben. Dieses Design senkt zudem die Kosten und liefert Updates zugleich an alle aus. Dafür entscheidet der Anbieter, wann sich eine Funktion ändert, und nicht Sie. Es lohnt sich deshalb, Änderungsankündigungen zu verfolgen und kritische Abläufe darauf zu prüfen.

Wer verantwortet was? Wie funktioniert das Modell der geteilten Verantwortung?

Erstens teilt sich in jedem Modell die Verantwortung auf Ebenen auf. Zweitens betreibt in der Regel der Anbieter die unteren, physischen Ebenen betreibt in der Regel der Anbieter, die oberen betreiben Sie. Die Grenze wandert von Modell zu Modell nach oben oder unten, wie die folgende Tabelle zeigt.

Die wichtigste Zeile ist die zweite, denn die Verantwortung für Ihre Daten und dafür, wer darauf zugreift, geht in keinem Modell an den Anbieter über. Anbieter veröffentlichen diesen Gedanken als "Modell der geteilten Verantwortung". Die Seite zum Shared Responsibility Model von AWS erklärt es zum Beispiel für die eigenen Dienste. Die Details unterscheiden sich je nach Anbieter, daher sollten Sie die aktuelle Aufteilung im Vertrag lesen.

Zwei Hinweise helfen beim Lesen der Tabelle. Erstens sinkt die Zahl der Ebenen, die Sie verwalten, von links nach rechts, erreicht aber nie null. Zweitens heißt "Anbieter" nicht automatisch, dass die Arbeit gut erledigt ist. Selbst wenn Patches und Backups beim Anbieter liegen, prüfen Sie Umfang und Häufigkeit in der Leistungsbeschreibung.

Warum gibt es diese drei Modelle und warum sind sie wichtig?

Früher bauten Unternehmen eigene Serverräume, kauften Hardware und pflegten sie selbst. Das bedeutete also hohe Anfangsinvestitionen und eine lange Einrichtungszeit. Die Cloud senkte diese Hürde, weil sie Ressourcen zur Miete machte. Servicemodelle legten danach einheitlich fest, auf welcher Ebene diese Miete beginnt.

Ihre Bedeutung lässt sich in drei Punkten zusammenfassen:

• Gemeinsame Sprache: Teams, Anbieter und Führungskräfte meinen mit denselben Wörtern dasselbe, daher werden Besprechungen kürzer.
• Klare Verantwortung: Bei einem Ausfall oder Sicherheitsvorfall weiß jeder sofort, wer wohin schaut.
• Bessere Entscheidungen: Kosten und Risiken lassen sich nur dann sinnvoll vergleichen, wenn Sie in der richtigen Kategorie vergleichen.

Wo passen FaaS und Serverless in diese drei Modelle?

FaaS steht für Function as a Service. Dabei laden Sie Code als kleine Funktionen hoch, die nur laufen, wenn ein Ereignis sie auslöst. Serverless beschreibt meist diesen Ansatz samt der verwalteten Dienste drumherum. Das heißt natürlich nicht, dass es keine Server gibt. Stattdessen verwaltet der Anbieter sie für Sie.

In der ursprünglichen NIST Definition taucht FaaS nicht als eigenes Modell auf. Daher behandelt die Branche es meist als dünnere Form von PaaS. Der Unterschied ist einfach: Bei PaaS liegt Ihre Anwendung in einer Umgebung, die dauerhaft läuft, bei FaaS läuft die Funktion nur bei Bedarf und verbraucht im Leerlauf keine Ressourcen.

Eine bekannte Frage dazu ist die Verzögerung beim ersten Aufruf. Diese und die Frage, wann Serverless passt, behandeln wir in einem eigenen Artikel: Was ist Serverless und Cold Start. Deshalb wiederholen wir sie hier nicht.

Wie vergleichen sich IaaS, PaaS, SaaS und die eigene Infrastruktur?

Der folgende Vergleich stellt die vier Ansätze aus Unternehmenssicht nebeneinander. Die Werte sind qualitativ, also enthalten sie weder Preise noch Zeiten, denn diese ändern sich je nach Anbieter und Zeitpunkt.

Die einfache Lehre aus der Tabelle lautet also: Mit der Kontrolle wächst die Verantwortung. Anders gesagt gibt es kein "bestes" Modell, sondern nur das, das zu Ihrer Arbeit und zur Stärke Ihres Teams passt.

Welche Beispielszenarien gibt es für jedes Modell?

Die vier Beispielszenarien unten sind frei erfunden und beschreiben keinen echten Kunden und kein reales Ergebnis. Sie zeigen lediglich, bei welchem Bedarf welches Modell überzeugt.

• IaaS Szenario: Ein mittelgroßes Unternehmen möchte ein individuelles Lagerprogramm umziehen, das seit Jahren auf dem eigenen Server läuft. Das Programm hängt an einer bestimmten Betriebssystemversion. Das Unternehmen mietet daher eine virtuelle Maschine, und so kommt die Anwendung nahezu unverändert in die Cloud.
• PaaS Szenario: Ein Team aus drei Personen entwickelt eine Terminbuchungs App. Niemand möchte Server verwalten. Stattdessen verbinden sie ihren Code mit einer Plattform, Datenbank und Skalierung sind bereit, und das Team baut nur noch Funktionen.
• Gemischtes Szenario: Ein Onlineshop Team nutzt die Shop Software als SaaS, betreibt die eigene Kampagnen Logik auf PaaS und lässt ein altes Auswertungswerkzeug auf IaaS laufen. Die Verantwortung unterscheidet sich je Teil, aber das Team führt alles in einer Tabelle.
• SaaS Szenario: Ein kleines Studio abonniert ein fertiges CRM für Kundenverwaltung und Angebote. Es startet am selben Tag und muss danach keine Softwareupdates verfolgen.

Produktnamen nennen wir bewusst nicht, denn entscheidend ist die Logik des Modells. Daher gilt dieselbe Logik bei jedem Anbieter.

Wie unterscheiden sich die Modelle bei der Kostenplanung?

Kosten nur an der Monatsrechnung zu messen, führt in die Irre. Die Gesamtbetriebskosten (englisch Total Cost of Ownership, TCO) umfassen Lizenzen, Ressourcenverbrauch, die Zeit Ihres Teams und den Schaden bei einem Ausfall. In diesem Artikel nennen wir deshalb keine Preise. Prüfen Sie aktuelle Tarife stattdessen auf den offiziellen Seiten des Anbieters.

Das Kostenverhalten der Modelle unterscheidet sich so:

• IaaS: Die Kosten folgen den genutzten Ressourcen. Eine ungenutzte virtuelle Maschine verursacht trotzdem Kosten, daher brauchen Sie Disziplin bei Überwachung und Abschaltung.
• PaaS: Die Kosten wachsen meist mit Anwendungsgröße und Verkehr. Der Betriebsaufwand sinkt, die Rechnung kann aber ebenfalls mit der Plattformnutzung steigen.
• SaaS: Die Kosten hängen meist von der Nutzerzahl oder vom Tarif ab. Das ist am besten planbar, allerdings wächst die Summe mit Ihrer Mitarbeiterzahl.

Andererseits hilft in allen drei Modellen eine Nutzungsobergrenze mit Warnschwelle. So erleben Sie am Monatsende keine böse Überraschung.

Was ist Anbieterbindung und wie verringern Sie sie?

Anbieterbindung (englisch Vendor Lock in) heißt, dass Sie so stark von den Spezialfunktionen eines Anbieters abhängen, dass ein Wechsel teuer oder praktisch unmöglich wird. Bei SaaS können Datenformate und Integrationen dazu führen. Bei PaaS sind es plattformspezifische Dienste, bei IaaS anbieterspezifische Verwaltungswerkzeuge.

Das Risiko lässt sich nicht ganz beseitigen, doch Sie können es verringern:

1. Exportieren Sie Ihre Daten regelmäßig in einem Standardformat und testen Sie die Wiederherstellung wirklich.
2. Verpacken Sie Ihre Anwendung möglichst portabel, denn der Container Ansatz hilft dabei.
3. Beantworten Sie vor der Wahl eines anbieterspezifischen Dienstes schriftlich: "Was passiert, wenn wir das morgen ersetzen müssen?"
4. Lesen Sie die Bedingungen zur Datenrückgabe und zur Beendigung des Dienstes im Vertrag.
5. Ziehen Sie bei gleichwertigen Optionen das Produkt vor, das offene Standards unterstützt.

Wie Docker und Kubernetes zusammenhängen, erfahren Sie außerdem im Artikel Docker und Kubernetes im Unterschied.

Wie wirken sich Datenstandort und DSGVO auf Cloud Modelle aus?

In welchem Land Ihre Daten liegen, welcher Anbieter sie hält und unter welchen Bedingungen, ist daher rechtlich relevant. Verarbeiten Sie personenbezogene Daten, gilt in Europa die DSGVO (Datenschutz Grundverordnung). Dieser Abschnitt gibt allgemeine Hinweise und ist keine Rechtsberatung, deshalb klären Sie Ihren Einzelfall mit einer qualifizierten Fachperson.

Der Rahmen ist in jedem Modell ähnlich:

• Meist sind Sie der Verantwortliche, während der Anbieter in Ihrem Auftrag als Auftragsverarbeiter handeln kann.
• Prüfen Sie zunächst im Vertrag die Speicherregion und die Bedingungen für Übermittlungen in Drittländer.
• Fragen Sie außerdem, wo Backups und Protokolle liegen.
• Verlangen Sie dann die Liste der Unterauftragsverarbeiter, also der weiteren Firmen, die Ihr Anbieter einsetzt.

Zur Website Seite der Konformität lesen Sie auch unseren Leitfaden Datenschutzkonforme Website nach DSGVO. Für den Gesetzestext selbst ist die offizielle EU Seite zur DSGVO der sicherste Weg.

Welcher Teil der Cloud Sicherheit bleibt bei Ihnen?

Der Anbieter schützt die physische Anlage und die Infrastruktur, aber die Sicherheit Ihres Kontos liegt in Ihrer Hand. Denn viele Cloud Vorfälle entstehen nicht durch raffinierte Angriffe, sondern durch Fehlkonfiguration und schwache Zugriffskontrolle. Daher brauchen Sie in jedem Modell dieselben Grundlagen.

• Zunächst aktivieren Sie die Mehrfaktor Authentifizierung (MFA) für alle Administratorkonten.
• Dann geben Sie jedem Nutzer nur die Rechte, die seine Aufgabe verlangt.
• Prüfen Sie öffentlich erreichbare Speicher und unnötig offene Ports regelmäßig.
• Bewahren Sie Backups an einem getrennten Ort auf und testen Sie dann die Wiederherstellung.
• Beobachten Sie zudem Zertifikat und Domain Einstellungen. Unser SSL Check zeigt den Zustand Ihres Zertifikats schnell.

Wenn Sie Berechtigungen zwischen Anwendungen aufbauen, erklärt der Artikel Was ist OAuth 2.0 die Logik von Identität und Rechten in einfacher Sprache.

Können Sie ein eigenes PaaS auf dem eigenen Server aufbauen?

Ja, das geht. Zunächst mieten Sie IaaS oder einen VPS und richten dann eine PaaS ähnliche Schicht darauf ein. So steuern Sie Bereitstellung, SSL und Datenbanken über ein Panel, aber der Server darunter bleibt Ihre Aufgabe. Anders gesagt ziehen Sie die Verantwortungslinie nach unten.

Der Reiz dieses Ansatzes sind Kontrolle und Planbarkeit. Das Risiko ist allerdings, dass Backups, Sicherheitspatches und Überwachung bei Ihnen bleiben. Für ein kleines Team kann diese zusätzliche Last schwerer wiegen als der Preis eines fertigen PaaS. Rechnen Sie deshalb den Wert Ihrer eigenen Zeit mit ein, bevor Sie entscheiden.

Für diese Option haben wir einen eigenen Leitfaden: Was ist Coolify und wie installieren Sie es auf dem eigenen Server. Hier ordnen wir sie daher nur im Modell ein. Wenn Sie nebenbei Ihre Domain Einträge prüfen möchten, hilft die DNS Abfrage.

Sind Cloud, Virtualisierung, Hosting und Container dasselbe?

Nein, aber sie werden oft verwechselt, denn alle kreisen um die Idee, einen Server zu mieten. Eine kurze Abgrenzung räumt daher das meiste Durcheinander auf.

• Cloud Computing: Das allgemeine Modell, das Ressourcen über ein Netzwerk bedarfsgerecht und mit gemessener Nutzung liefert. IaaS, PaaS und SaaS sind seine Dienstebenen.
• Virtualisierung: Die Technik, die eine physische Maschine in viele virtuelle teilt. Sie ist ein Baustein der Cloud, aber nicht die Cloud selbst.
• Hosting: Das Mieten von Platz für Ihre Website. Geteiltes Hosting liegt zum Beispiel oft irgendwo zwischen PaaS und SaaS.
• Container: Portable Einheiten, die eine Anwendung samt Abhängigkeiten bündeln. Dadurch bleibt Ihre Anwendung in jedem Modell beweglich.
• Kubernetes: Ein Orchestrierungssystem, das viele Container verwaltet. Meist läuft es dann auf IaaS oder PaaS.

Welches Content Management System Ihre eigene Website nutzt, zeigt der CMS Checker als ersten Hinweis.

Überschneiden sich Servicemodelle mit öffentlicher, privater, hybrider und Multicloud?

Nein, doch sie werden häufig vermischt. Servicemodelle beschreiben, was Sie erhalten, Bereitstellungsmodelle dagegen, wem die Cloud gehört. Das sind also unabhängige Achsen. Sie können zum Beispiel IaaS oder SaaS in einer öffentlichen Cloud beziehen.

• Öffentliche Cloud: Ein Anbieter stellt Infrastruktur offen für alle bereit, also nicht nur für einen Kunden.
• Private Cloud: Die Infrastruktur dient nur einer Organisation, und entweder sie selbst oder ein Dritter betreibt sie.
• Gemeinschaftliche Cloud: Mehrere Organisationen mit ähnlichem Bedarf teilen sich die Infrastruktur.
• Hybride Cloud: Sie verbinden stattdessen zwei oder mehr Bereitstellungsmodelle und nutzen sie gemeinsam.

Multicloud bedeutet, Dienste verschiedener Anbieter zu kombinieren. Das kann die Anbieterbindung senken, erhöht aber zugleich den Verwaltungsaufwand. Für kleine Teams ist ein einfacher Start bei einem Anbieter oft gesünder.

Was bedeuten CaaS, DaaS, BaaS und XaaS?

Das Muster "als Dienst" hat sich in der Branche stark vermehrt. Diese Kürzel sind keine offiziellen Standards, sondern entstammen der Marketing und Ingenieursprache. Daher definieren verschiedene Quellen sie teils leicht unterschiedlich.

• CaaS (Container as a Service): Eine fertige Plattform zum Betreiben und Verwalten von Containern.
• DaaS (Desktop as a Service): Ein virtueller Desktop, den die Cloud statt eines lokalen PCs liefert.
• BaaS (Backend as a Service): Fertige Backend Bausteine für Mobile und Web Apps, sodass Entwickler Serverarbeit sparen.
• XaaS: Ein Sammelbegriff für "alles als Dienst".

Die meisten passen irgendwo in die drei Kernmodelle, sonst wären sie schwer einzuordnen. Wenn Sie ein neues Produkt sehen, ist die Frage "Was verwalte ich hier?" deshalb ein verlässlicherer Wegweiser als das Kürzel.

Wie hängen APIs, DevOps und Datenbankwahl mit diesen Modellen zusammen?

Die Wahl des Cloud Modells reicht allein nicht aus, denn auch die Teile darüber zählen. Eine API ist die Brücke, die SaaS Produkte mit Ihren eigenen Systemen verbindet. Ein Kundendatensatz im CRM kann zum Beispiel über eine API in Ihr Rechnungssystem fließen.

DevOps ist die gemeinsame Arbeitskultur von Entwicklung und Betrieb. Bei IaaS und PaaS entscheiden Gewohnheiten wie automatische Bereitstellung und Überwachung über das Ergebnis. Somit zählt, wie Sie ein Modell betreiben, genauso wie die Frage, welches Sie wählen.

Bei Datenbanken gibt es eine ähnliche Aufteilung. Installieren und betreiben Sie eine Datenbank selbst, folgt das der IaaS Logik. Nutzen Sie dagegen eine vom Anbieter verwaltete Datenbank, nähern Sie sich der PaaS Logik. Welche Datenart zu welcher Datenbank passt, lesen Sie in Was ist NoSQL und wie unterscheidet es sich von SQL.

Welches Modell passt zu Ihnen und was bedeutet der IaaS PaaS SaaS Unterschied dafür?

Eine praktische Reihenfolge hilft: Prüfen Sie zunächst, ob ein fertiges SaaS Produkt Ihren Bedarf deckt. Wenn nicht, denken Sie an PaaS, und wenn PaaS nicht reicht, an IaaS. So starten Sie mit der geringsten Betriebslast und erhöhen die Kontrolle nur, wenn es nötig ist.

• SaaS passt, wenn Ihr Bedarf ein gängiger Geschäftsprozess wie E-Mail, Kalender, Kundenverwaltung oder Projektplanung ist und Sie keine Sonderregel haben.
• PaaS passt, wenn Sie eigene Software entwickeln, Ihr Team für den Serverbetrieb klein ist und Sie schnell veröffentlichen möchten.
• IaaS passt, wenn Sie ein besonderes Betriebssystem, eine Lizenz oder ein Netzwerkdesign brauchen oder eine bestehende Anwendung zügig umziehen.
• Die eigene Infrastruktur passt, wenn Vorschriften, Latenz oder sehr spezielle Hardware keine andere Wahl lassen.

Die eigene Infrastruktur bleibt gültig. Sie ist zum Beispiel sinnvoll, wenn Netzwerklatenz kritisch ist, lokale Regeln einen festen Standort der Daten verlangen oder Sonderhardware im Einsatz ist. Treffen Sie diese Wahl dennoch bewusst und nicht aus Gewohnheit.

Die meisten Unternehmen nutzen nämlich nicht nur ein Modell. Büroarbeit auf SaaS, das eigene Produkt auf PaaS und ein altes System auf IaaS können zum Beispiel nebeneinander bestehen. Vor allem zählt, dass Sie bei jedem Teil wissen, wer verantwortlich ist.

Was gehört in eine Checkliste zum IaaS PaaS SaaS Unterschied vor der Entscheidung?

Die Liste unten sammelt Fragen, die Sie mit Ihrem Team beantworten können, bevor Sie einen Anbieter oder ein Modell wählen. Schriftliche Antworten erinnern Sie außerdem nach sechs Monaten daran, warum Sie so entschieden haben.

1. Gibt es für diese Aufgabe ein fertiges SaaS Produkt, und deckt es unseren Bedarf wirklich ab?
2. Hat unser Team jemanden für Serverbetrieb, Patches und Überwachung?
3. Brauchen wir ein besonderes Betriebssystem, eine bestimmte Softwareversion oder eine Lizenz?
4. In welchem Land liegen unsere Daten, und welche Arten personenbezogener Daten enthalten sie?
5. Wenn wir den Anbieter verlassen wollen, in welchem Format und wie leicht bekommen wir die Daten zurück?
6. Wie verhalten sich die Kosten beim Wachsen, und können wir eine Ausgabenwarnung setzen?
7. Wer ist für Backup und Wiederherstellung verantwortlich?
8. Wie verwalten wir Authentifizierung und Autorisierung?

Es ist normal, wenn Sie die meisten Fragen nicht sofort klar beantworten können. Dann starten Sie in diesem Fall mit einem kleinen Pilotprojekt und passen Sie das Modell an, sobald Sie mehr wissen.

Welche Fehler passieren bei der Wahl eines Cloud Modells am häufigsten?

Dieselben Fehler wiederholen sich in vielen Teams. Wer sie kennt, spart daher Zeit und Mühe.

• Annehmen, die Cloud sei von Haus aus sicher. Kontosicherheit und Konfiguration bleiben bei Ihnen.
• Ungenutzte Ressourcen weiterlaufen lassen. Vor allem bei IaaS verursacht eine Maschine im Leerlauf Kosten.
• Nie eine Wiederherstellung testen, denn ein Backup zählt erst, wenn es zurückkommt.
• Sich ohne Ausstiegsplan an Spezialdienste eines Anbieters binden.
• Datenexport und API Unterstützung bei der SaaS Wahl übergehen.
• Das Modell nur nach der Rechnung des ersten Monats wählen.
• "Der Anbieter regelt das" sagen, ohne die Aufteilung der Verantwortung im Vertrag zu lesen.

Keiner dieser Fehler ist technisch schwer. Dennoch passieren sie, denn die meisten entstehen stattdessen durch eine übersprungene Prüfung in einer hastigen Entscheidung. Folglich lautet die gemeinsame Wurzel: Die Frage "Wer verwaltet was?" wurde am Anfang nie geklärt. Als erster Weg, sie zu stellen, eignet sich die Tabelle in diesem Artikel.

Wie klären Sie das Cloud Modell in einem individuellen Softwareprojekt?

Bei individueller Software gehört das Cloud Modell zu den frühesten Architekturentscheidungen. Das gewählte Modell bestimmt, wie Sie den Code verpacken, welche Dienste Sie fertig zukaufen und womit sich Ihr Team befasst. Ein späterer Wechsel ist zwar möglich, kostet aber Geld.

Wir von Talha Aslan und Team beginnen Softwareprojekte daher mit einem Gespräch über das Geschäftsziel und die Kapazität des Teams. Danach trennen wir, welche Teile ein fertiges SaaS Produkt abdeckt und welche Sie selbst entwickeln sollten. Diesen Plan klären wir gemeinsam im Rahmen unserer individuellen Softwareentwicklung.

Schließlich sind IaaS, PaaS und SaaS kein Wettlauf, sondern eine Entscheidung darüber, wie Sie Verantwortung aufteilen. Somit liegt das richtige Modell dort, wo Ihr Geschäftsbedarf auf die Stärke Ihres Teams trifft. Als offizielle Ergänzung eignen sich der Modellvergleich von Google Cloud und die Erklärung zu IaaS von Azure.