Die Wahl der Betriebsplattform wird meist als Kostenfrage geführt und ist in Wahrheit eine Frage danach, wofür ein Team seine Zeit ausgeben will. Beide Wege funktionieren; sie verlagern den Aufwand nur an unterschiedliche Stellen.
Was eine verwaltete Plattform tatsächlich abnimmt
Der offensichtliche Teil ist die Bereitstellung: Code hochladen, fertig. Der grössere Teil ist unsichtbar — Zertifikate, Auslieferung über ein Verteilnetz, Vorschauumgebungen pro Änderung, Rollback per Klick, Skalierung ohne Konfiguration.
Für ein kleines Team ist das kein Komfort, sondern der Unterschied zwischen Zeit für das Produkt und Zeit für Infrastruktur. Wer diesen Aufwand auf einer allgemeinen Cloud-Plattform nachbauen will, baut mehrere Wochen und betreibt danach dauerhaft.
Wo verwaltete Plattformen teuer werden
Die Kostenmodelle rechnen über Ausführungszeit, Aufrufe und ausgehenden Datenverkehr ab. Für ein typisches B2B-Produkt mit überschaubarem Verkehr bleibt das lange unauffällig.
Unangenehm wird es bei Anwendungen, die grosse Datenmengen ausliefern, bei sehr rechenintensiven Vorgängen und bei Aufgaben, die lange laufen. Ein Bildverarbeitungsdienst oder ein Export über grosse Datenmengen ist in diesem Modell schlecht aufgehoben.
Die praktische Empfehlung: das erwartete Lastprofil gegen die aktuellen Preisseiten rechnen, bevor die Entscheidung fällt — und dabei den ausgehenden Datenverkehr nicht vergessen, der in Schätzungen regelmässig fehlt.
Datenresidenz ist mehr als die Region der Anwendung
Für DACH-Kunden ist die Region ein wiederkehrendes Thema im Einkauf. Wichtig ist, dass die Frage sich nicht auf die Ausführung der Anwendung beschränkt.
Zu prüfen sind: Wo läuft die Anwendung, wo liegt die Datenbank, wo liegen Sicherungen, wo werden Protokolle gespeichert, wo laufen Zwischenspeicher und Verteilnetz, und wo sitzen die Werkzeuge, die Ihr Support benutzt. Sechs Fragen, die oft als eine behandelt werden.
Bei verwalteten Plattformen sind einige dieser Punkte nicht frei wählbar. Das ist kein Ausschlusskriterium, muss aber bekannt sein, bevor jemand im Fragebogen ankreuzt, dass alle Daten in Europa liegen.
Der Mischbetrieb ist der Normalfall
In der Praxis läuft die häufigste Aufteilung nicht auf ein Entweder-oder hinaus: Anwendung auf einer verwalteten Plattform, Datenbank bei einem spezialisierten Anbieter in gewählter Region, rechenintensive oder lang laufende Aufgaben auf einer allgemeinen Cloud-Plattform.
Das ist kein Kompromiss aus Unentschiedenheit, sondern eine sinnvolle Trennung: Die Teile, bei denen Entwicklungsgeschwindigkeit zählt, bekommen Komfort; die Teile, bei denen Kosten oder Kontrolle zählen, bekommen Kontrolle.
Wann ein Wechsel ansteht
Drei Anlässe rechtfertigen den Umbau. Erstens, wenn die Betriebskosten in eine Grössenordnung wachsen, in der eine eigene Betriebsmannschaft günstiger wäre. Zweitens, wenn Kundenanforderungen eine Kontrolle verlangen, die die Plattform nicht hergibt. Drittens, wenn Aufgaben nötig werden, die im Ausführungsmodell der Plattform nicht laufen.
Kein Anlass ist das Gefühl, dass man es selbst besser könnte. Ein Wechsel bindet Wochen, in denen niemand am Produkt arbeitet.
Was den Wechsel offenhält
Wer sich die Option erhalten will, sollte drei Dinge vermeiden: anbieterspezifische Funktionen im Kern der Anwendung, den Betrieb der Datenbank durch dieselbe Plattform, und Bereitstellungsschritte, die nur in der Oberfläche des Anbieters existieren statt in einer Datei im Repository.
Diese drei Regeln kosten wenig und halten den Umzug bei einer Teilaufgabe von Wochen statt bei einer Neuentwicklung.