Hosting selbst betreiben vs. Managed Operator

Betrieb beginnt, wenn das Projekt endet

Viele planen ein Software-Projekt bis zum Launch und schieben den Betrieb als Restposten hinterher, der sich danach schon irgendwie regelt. Tatsächlich startet der Betrieb in dem Moment, in dem sich die erste Nutzerin einloggt, und er hört erst auf, wenn das Produkt abgeschaltet wird. Dazwischen liegen Updates, Sicherheitslücken, Backups, Lastspitzen, Datenbankmigrationen und dieser eine Moment, in dem ein Deployment kippt und jemand entscheiden muss, was jetzt passiert.

Die Frage ist also nicht, ob dein Produkt Betrieb braucht, sondern wer ihn übernimmt. Drei grundsätzliche Wege stehen dir offen: Du hostest selbst, du nutzt eine Cloud-Plattform, die dir einen Teil der Arbeit abnimmt, oder du gibst den Betrieb an einen Operator-Partner. Der Unterschied liegt weniger im Preis als darin, wo die Verantwortung sitzt und wer im Ernstfall handelt. Gehen wir sie der Reihe nach durch und stellen sie danach entlang von vier Treibern gegenüber: Aufwand, Risiko, Kosten und Reaktion im Störfall.

Selbst hosten: volle Kontrolle, volle Verantwortung

Selbst hosten heisst, dass du die Infrastruktur selbst aufsetzt und pflegst. Ein eigener Server im Rechenzentrum, eine virtuelle Maschine in der Cloud oder ein Cluster, den dein Team verwaltet. Vom Betriebssystem über die Datenbank bis zum Deployment-Prozess liegt alles in deiner Hand.

Der Gewinn ist Kontrolle. Du entscheidest über jede Komponente, steckst in keinem Plattform-Korsett und kannst auf der Ebene der reinen Rechenleistung optimieren. Bei besonderen Anforderungen an Datenhoheit, Latenz oder einen ungewöhnlichen Software-Stack ist das manchmal der einzige gangbare Weg.

Der Preis ist Verantwortung, und die verschwindet nicht, nur weil gerade niemand hinschaut. Sicherheitsupdates wollen eingespielt werden, sonst wird aus einer bekannten Lücke ein offenes Tor. Backups müssen nicht nur laufen, sie müssen sich auch wiederherstellen lassen, und das sind zwei verschiedene Dinge. Steigt die Last, skalierst du selbst. Und stürzt nachts ein Dienst ab, klingelt das Telefon bei dir oder bei niemandem. Selbst hosten bedeutet deshalb vor allem eines: Du brauchst Menschen mit Betriebs-Know-how, die erreichbar bleiben, auch wenn das Entwicklungsprojekt längst abgeschlossen ist. Dieser Punkt wird gern übersehen, weil die Infrastruktur-Rechnung günstig wirkt. Die Personalrechnung dahinter tut es nicht.

Cloud-managed: Arbeit auslagern, Kontrolle teilen

In der Mitte liegen managed Cloud-Dienste. Hier übernimmt eine Plattform einen Teil der Betriebsarbeit. Eine managed Datenbank kümmert sich um Backups, Failover und die Updates der Datenbank-Software. Eine Plattform fürs Application-Hosting nimmt dir Server-Pflege und Skalierung ab und liefert fertige Deployment-Pipelines. Du bringst deinen Code, die Plattform sorgt dafür, dass er läuft.

Das druckt den Betriebsaufwand spürbar nach unten, weil ganze Aufgabenfelder beim Anbieter liegen. Kein Betriebssystem patchen, kein eigenes Backup-Konzept für die Datenbank bauen. Für viele Produkte ist das ein guter Mittelweg, besonders früh, wenn du Tempo brauchst und noch nicht weisst, wie sich die Last entwickelt. Wenn du gerade überlegst, wie du überhaupt loslegst, hilft ein Blick darauf, welche Wege es gibt, ein MVP zu bauen. Die Betriebsfrage hängt eng daran, wie du baust.

Grenzen hat dieser Weg an zwei Stellen. Du gibst Kontrolle ab und bewegst dich im Rahmen dessen, was die Plattform vorsieht. Ungewöhnliche Anforderungen lassen sich nicht immer umsetzen. Und managed deckt nur die Plattform-Ebene ab, nicht dein Produkt. Hängt ein Cron-Job, verbiegt eine Migration deine Daten oder bricht ein Feature unter Last zusammen, ist das dein Problem, nicht das der Plattform. Cloud-managed nimmt dir die Maschine ab, aber nicht die Anwendung. Die Frage, wer reagiert, wenn es klemmt, ist damit nur halb beantwortet: für die Infrastruktur ja, für dein eigentliches Produkt nein.

Operator-Partner: Betrieb als Verantwortung, nicht als Werkzeug

Der dritte Weg ist ein Operator-Partner, also jemand, der den Betrieb deines konkreten Produkts übernimmt und nicht nur die Infrastruktur darunter. Die Plattform-Ebene gehört dazu, aber es geht weiter: Monitoring auf Anwendungs-Ebene, Reaktion auf Störungen, Updates einspielen, Abhängigkeiten pflegen, entscheiden, wenn ein Deployment kippt. Anders als bei Cloud-managed endet der Verantwortungsbereich nicht an der Plattform-Grenze, er umfasst dein Produkt.

Deinen eigenen Aufwand senkt das am stärksten, weil du das Thema Betrieb als Ganzes abgibst, statt es in Einzelteile zu zerlegen und selbst zusammenzuhalten. Auch das Risiko wandert: Wer das Produkt betreibt, will, dass es läuft, und sieht Probleme oft, bevor du sie überhaupt bemerkst. Daran hängt aber eine Bedingung, die du prüfen solltest. Ein Operator-Partner taugt nur, wenn er das Produkt versteht, im Störfall erreichbar ist und auch handeln darf.

Schau dir an, wer da betreibt. Eine reine Entwicklungsagentur baut und übergibt, danach ist Schluss. Wer eigene Produkte betreibt, kennt den Betriebsalltag aus erster Hand. Bei Wertstifter ist das kein Nebenversprechen: Wir betreiben mit Wortfreunde und Reazon eigene Produkte und tragen dort dieselbe Betriebsverantwortung wie für Kundenprodukte. Was das konkret heisst, steht unter Produkt-Betrieb und Skalierung. Es geht nicht ums Logo, sondern um die Haltung: Betrieb ist eine fortlaufende Verantwortung und kein abgeschlossenes Projekt.

Aufwand, Risiko, Kosten und Reaktion im direkten Vergleich

Um die drei Wege sauber gegeneinanderzulegen, lohnt es, dieselben vier Treiber bei jedem durchzuspielen.

Aufwand. Selbst hosten verlangt den höchsten laufenden Aufwand, weil jede Betriebsaufgabe bei dir bleibt. Cloud-managed senkt ihn, indem es die Plattform-Ebene abdeckt. Ein Operator-Partner senkt ihn am stärksten, weil auch die Anwendungs-Ebene mit drin ist. Dieser Aufwand fällt nicht einmalig an, sondern Monat für Monat, über die gesamte Lebensdauer des Produkts.

Risiko. Risiko meint hier vor allem: Was passiert bei einem Ausfall, und wie schnell ist er behoben. Beim Selbst-Hosting trägst du das volle Risiko, hast dafür aber maximale Kontrolle über die Behebung. Cloud-managed schiebt das Infrastruktur-Risiko zum Anbieter und lässt dir das Produkt-Risiko. Ein Operator-Partner deckt beide Ebenen ab, womit dein Restrisiko am kleinsten wird, vorausgesetzt, der Partner ist verlässlich. Ein schwacher oder schwer erreichbarer Partner beseitigt das Risiko nicht, er versteckt es nur.

Kosten. Kosten lassen sich nicht in einer Zahl fassen, nur über ihre Treiber. Beim Selbst-Hosting ist die reine Infrastruktur oft am günstigsten, die versteckten Kosten stecken in der Personenzeit für Betrieb und Bereitschaft. Cloud-managed kostet pro Ressource auf der Rechnung mehr, spart aber Personenzeit, weil Betriebsaufgaben wegfallen. Ein Operator-Partner bündelt diese Personenzeit in einer planbaren Leistung. Die bessere Frage als was ist billiger lautet deshalb: Welche Kosten siehst du auf der Rechnung, und welche entstehen unsichtbar in deinem eigenen Team. Wie sich solche Gesamtkosten über die Lebensdauer aufbauen, zeigt auch der Artikel dazu, was ein MVP kostet.

Reaktion, wenn es klemmt. Dieser Treiber wird am häufigsten vergessen und tut am meisten weh. Beim Selbst-Hosting reagiert dein Team, sofern es gerade verfügbar ist. Cloud-managed reagiert auf Infrastruktur-Ebene, deine Anwendung interessiert dabei niemanden. Nur beim Operator-Partner ist jemand für das gesamte Produkt ansprechbar. Stell dir die Szene konkret vor: Ein Update einer Abhängigkeit bricht nachts das Login. Beim Selbst-Hosting muss jemand aus deinem Team aufstehen. Bei Cloud-managed läuft die Plattform stabil, dein Login nicht, und der Anbieter ist nicht zuständig. Beim Operator-Partner schlägt das Monitoring an, jemand greift ein, und am Morgen liegt eine Notiz vor, was passiert ist.

Wann welcher Weg passt, und wann nicht

Keiner der drei Wege ist generell besser. Sie passen zu unterschiedlichen Lagen.

Selbst hosten passt, wenn du eigenes Betriebs-Know-how im Haus hast, das auch langfristig bleibt, und wenn besondere Anforderungen an Datenhoheit oder Architektur dich ohnehin zwingen, die Kontrolle zu behalten. Es passt schlecht, wenn der Betrieb am Ende an einer einzelnen Person hängt, die nebenbei entwickelt und irgendwann auch mal Urlaub macht.

Cloud-managed passt in frühen Phasen, in denen du Tempo brauchst und die Last noch unklar ist, und immer dann, wenn dein Team die Anwendung selbst betreuen kann, aber die Maschine darunter nicht pflegen will. Ein guter Standard für viele Produkte und oft der richtige Startpunkt, gerade wenn du sowieso abwägst, ob sich eigenes SaaS für ein KMU lohnt.

Ein Operator-Partner passt, wenn dein Produkt geschäftskritisch ist, wenn du kein eigenes Betriebsteam aufbauen willst und wenn dir wichtig ist, dass jemand das ganze Produkt im Blick hat statt nur die Infrastruktur. Der Weg mit dem geringsten eigenen Aufwand und dem kleinsten Restrisiko, solange der Partner verlässlich ist und das Produkt wirklich versteht. Lohnt sich das für ein kleines Wochenend-Tool ohne echte Nutzer? Eher nicht. Da bist du mit Cloud-managed oder einem schlanken Selbst-Hosting besser bedient, denn für einen Operator-Partner zahlst du eine laufende Leistung, die sich erst rechnet, wenn Ausfälle dich wirklich Geld oder Vertrauen kosten.

In der Praxis sind die Übergänge fliessend. Viele Produkte starten Cloud-managed und holen sich einen Operator-Partner dazu, sobald der Betrieb geschäftskritisch wird. Andere bleiben bewusst beim Selbst-Hosting, weil ihr Team das kann und will. Wichtig ist nur, dass du die Betriebsfrage stellst, bevor das Produkt live geht, und nicht erst in der Nacht, in der zum ersten Mal etwas klemmt. Wer den Betrieb von Anfang an mitdenkt, umgeht einen der häufigeren Gründe, warum SaaS-Projekte scheitern: nicht das Bauen, sondern das, was danach kommt.