Die Cloud ist billiger. Bis die Leitung weg ist.

Warum zentrale Webanwendungen in der Dauerkrise ein dezentrales Fundament brauchen

Zwanzig Jahre lang hat in der IT ein Argument fast jede Debatte entschieden: Total Cost of Ownership. Wer die Gesamtkosten einer Software über ihren Lebenszyklus ehrlich rechnet, landet selten beim klassischen Arbeitsplatzprogramm. Er landet bei der zentralen, webbasierten Anwendung, die einmal betrieben und überall im Browser genutzt wird.

Dieses Argument war richtig. Es beruhte aber auf einer Annahme, die nie jemand aufgeschrieben hat: Strom und Internet sind immer da. Gilt diese Annahme über längere Zeit nicht mehr, wird aus dem Kostenvorteil ein Klumpenrisiko. Dann zählt nicht mehr, wo eine Anwendung am billigsten läuft. Dann zählt nur noch, ob sie läuft.

Dieser Artikel zeigt, wie TCO die Zentralisierung vorangetrieben hat, wo die blinde Stelle dieser Rechnung liegt und warum Container-Konzepte, die zentral und dezentral zugleich arbeiten, unter Krisenbedingungen überlebenswichtig sind. Und er zeigt an zwei laufenden Projekten aus dem Gesundheitswesen, dass das keine Theorie ist.

1. Wie TCO die Zentralisierung angetrieben hat

Die Fat-Client-Ära: teuer im Kleinen

Die klassische Branchensoftware, ob in der Arztpraxis, im Handwerksbetrieb oder in der Kanzlei, war über Jahre ein Programm auf jedem Arbeitsplatz, oft mit einer lokalen Datenbank auf einem Server im Abstellraum. Die Anschaffung war überschaubar. Teuer wurde der Betrieb:

• Installation und Updates pro Arbeitsplatz: Jede neue Version musste auf jeden Rechner gebracht werden, oft durch einen Techniker vor Ort.
• Abhängigkeiten: Betriebssystemversion, Laufzeitumgebungen, Druckertreiber und Datenbankversion mussten zueinander passen. Ein Windows-Update konnte einen ganzen Betrieb stilllegen.
• Datensicherung in jedem Standort: Jeder Kunde brauchte sein eigenes Backup, und ob es im Ernstfall funktionierte, zeigte sich oft erst im Ernstfall.
• Sicherheit verteilt: Patches mussten auf vielen kleinen, unterschiedlich gepflegten Systemen eingespielt werden.
• Support: Jede Installation war ein bisschen anders. Fehlersuche bedeutete, erst einmal herauszufinden, was vor Ort überhaupt läuft.

Der Kaufpreis war nur die Spitze. Darunter lagen Personal, Fahrten, Ausfallzeiten und Fehler durch uneinheitliche Umgebungen.

Die Webanwendung: billig im Großen

Zentrale, webbasierte Anwendungen haben genau diese Kostenblöcke angegriffen:

• Ein Deployment statt tausend: Ein Update wird einmal ausgerollt und gilt sofort für alle.
• Der Browser als Client: Am Arbeitsplatz braucht es kaum mehr als einen aktuellen Browser. Hardware wird austauschbar und kann länger genutzt werden.
• Skaleneffekte: Rechenzentrum, Backup, Monitoring und Sicherheitsteam werden auf viele Kunden verteilt.
• Planbare Betriebskosten statt Investition: Abomodelle pro Nutzer oder Standort ersetzen große Einmalinvestitionen.
• Einheitliche Umgebung: Der Hersteller betreibt genau eine Version in genau einer Umgebung. Fehler lassen sich reproduzieren.

Auf dem Papier ist das Ergebnis eindeutig. Und in der Praxis war es lange auch so: Die Zentralisierung hat Betrieb vereinfacht, Sicherheit verbessert und kleine Organisationen von Aufgaben entlastet, für die sie nie aufgestellt waren.

2. Die blinde Stelle der TCO-Rechnung

Eine TCO-Rechnung summiert, was ein System kostet, solange es läuft. Was es kostet, wenn es nicht läuft, taucht meist nur als pauschale Verfügbarkeitszusage im Vertrag auf.

Die Verfügbarkeit einer zentralen Webanwendung ist aber nicht die Verfügbarkeit des Rechenzentrums. Sie ist das Produkt einer ganzen Kette:

1. Strom am Arbeitsplatz
2. Strom an Router und Netzwerktechnik vor Ort
3. Leitung zum Provider (Kupfer, Glasfaser, Mobilfunk)
4. Netz des Providers und dessen Stromversorgung
5. Internet-Knoten, Namensauflösung (DNS)
6. Rechenzentrum des Anbieters
7. Externe Dienste, an denen die Anwendung hängt: Anmeldung, Lizenzprüfung, Zahlungsdienste, Schnittstellen

Fällt ein Glied aus, steht die Anwendung für den Nutzer still, unabhängig davon, wie hochverfügbar das Rechenzentrum ist. Die Zentralisierung hat die Kosten gesenkt, aber die Abhängigkeit von dieser Kette maximiert. Der Fat Client hatte viele Schwächen, aber er lief, solange in der Praxis Strom war.

Solange Ausfälle kurz und selten sind, ist das ein vertretbarer Tausch. Die Frage ist, was passiert, wenn sie es nicht mehr sind.

3. Szenario: die längere strukturelle Krise

Gemeint ist hier nicht der eine große Blackout, über den gerne gesprochen wird. Gemeint ist eine Lage, die sich über Monate oder Jahre hinzieht und in der Störungen zum Normalbetrieb gehören. Denkbare Bausteine eines solchen Szenarios (ausdrücklich als Annahmen, nicht als Prognose):

• Instabile Stromversorgung: wiederkehrende regionale Abschaltungen oder Lastabwürfe, Spannungsschwankungen, Ausfälle über Stunden statt Minuten.
• Unzuverlässige Netzanbindung: beschädigte Leitungen, überlastete oder abgeschaltete Mobilfunkmasten, deren Notstrom nach kurzer Zeit erschöpft ist.
• Angriffe auf Dienstleister: Cyberangriffe auf Provider, Rechenzentren oder einzelne große Softwareanbieter, die viele Kunden gleichzeitig treffen.
• Lieferengpässe: Ersatzhardware ist nicht kurzfristig verfügbar, Technikereinsätze vor Ort sind knapp.

In einer solchen Lage kehrt sich die TCO-Logik um. Ein Tag, an dem eine Praxis keine Termine sieht, keine Befunde abrufen und nicht dokumentieren kann, kostet mehr als jede Ersparnis beim Betrieb. Bei Einrichtungen, an denen Versorgung hängt, geht es nicht mehr nur um Geld.

Die Antwort darauf ist aber nicht die Rückkehr zum Fat Client. Dessen Betriebsprobleme sind nicht verschwunden. Die Antwort ist eine Architektur, die die Vorteile der Zentralisierung behält und ihre Abhängigkeit auflöst.

4. Container als Brücke: dasselbe System, zwei Orte

Container-Technik, im Alltag meist Docker, ist genau das Werkzeug, das den Betriebsvorteil der Webanwendung transportabel macht. Ein Container-Image enthält die Anwendung samt Laufzeitumgebung. Es läuft im Rechenzentrum genauso wie auf einem kleinen Rechner vor Ort.

Damit wird möglich, was früher zwei getrennte Produkte erfordert hätte: eine zentrale Instanz für den Normalbetrieb und eine lokale Instanz für den Notbetrieb, aus demselben Artefakt.

Muster 1: Ein Image, zwei Rollen

Zentral und lokal läuft dasselbe Image. Was sich unterscheidet, ist nur die Konfiguration: Rolle, Datenbankverbindung, Synchronisationsziel. Damit gibt es keine „Notfallversion“, die nie getestet wird, sondern nur eine Version, die an zwei Orten läuft.

# Vereinfachtes Beispiel: gleiche Images, unterschiedliche Rolle per Profil
services:
  app:
    image: registry.example.local/beispiel-app:1.0.0
    environment:
      NODE_ROLE: ${NODE_ROLE}        # "central" oder "edge"
      DB_HOST: db
      SYNC_TARGET: ${SYNC_TARGET}    # bei edge: zentrale Instanz
    restart: unless-stopped
  db:
    image: registry.example.local/datenbank:1.0.0
    volumes:
      - daten:/var/lib/daten
    restart: unless-stopped
volumes:
  daten:

Muster 2: Eine führende Datenbank, klare Rollen

Der gefährlichste Fehler verteilter Systeme ist der Split Brain: Zentrale und lokale Instanz halten sich beide für führend, beide nehmen Änderungen an, und am Ende gibt es zwei Wahrheiten. Bewährt hat sich:

• Zu jedem Zeitpunkt gibt es genau eine führende Datenbank.
• Der Wechsel der Führung ist ein bewusster Schritt, etwa ein Knopf, den der Verantwortliche vor Ort drückt, kein automatischer Reflex bei jeder Netzstörung.
• Eine Instanz, die ihre Führungsrolle nicht mehr sicher bestätigen kann, sperrt sich selbst für Schreibzugriffe, statt weiterzuschreiben.

Das klingt weniger elegant als vollautomatische Hochverfügbarkeit. Es ist aber das, was unter unklaren Bedingungen zuverlässig funktioniert und was Menschen vor Ort verstehen.

Muster 3: Offline-fähig denken

Nicht jede Funktion muss lokal laufen. Aber die Funktionen, ohne die der Betrieb steht, müssen es. Dazu gehört:

• Lokale Warteschlangen für alles, was nach außen geht (Abrechnung, Übermittlungen, Bestellungen). Sie werden abgearbeitet, sobald die Leitung wieder steht.
• Eindeutige Konfliktregeln für den Abgleich: Was gilt, wenn derselbe Datensatz an zwei Orten geändert wurde?
• Sichtbarer Status in der Oberfläche: Der Nutzer muss sehen, ob er online, offline oder im Notbetrieb arbeitet und wie viele Vorgänge noch auf Übertragung warten.

Muster 4: Keine versteckten Abhängigkeiten nach außen

Eine lokale Instanz, die beim Start ein Image aus dem Internet ziehen, eine Lizenz online prüfen oder sich über einen externen Anmeldedienst authentifizieren muss, ist im Ernstfall wertlos. Deshalb gehören vor Ort dazu:

• Vorgehaltene Images eine lokale Registry: Im Notfall wird nichts heruntergeladen.
• Lokale Anmeldung als Rückfallebene.
• Zeit und Namensauflösung, die ohne Internet funktionieren.
• Lizenzmodelle, die eine Karenzzeit ohne Verbindung

Eine ehrliche Grenze gehört dazu: Manche Dienste sind von Natur aus online gebunden, etwa Prüfungen gegen zentrale Register oder der Austausch mit externen Stellen. Diese lassen sich lokal nicht ersetzen, wohl aber puffern, sodass der Betrieb weiterläuft und die Übermittlung nachgeholt wird.

Muster 5: Energie mitdenken

Unter Strommangel wird Leistungsaufnahme zur Architekturfrage. Ein lokaler Knoten muss nicht groß sein:

• Sparsame Hardware (Einplatinenrechner oder Mini-PC) reicht für viele Praxis- und Betriebsanwendungen.
• Eine USV oder ein Akkusystem überbrückt Ausfälle und erlaubt ein sauberes Herunterfahren.
• Router und Switch gehören an dieselbe Notversorgung, sonst läuft der Server, aber kein Arbeitsplatz erreicht ihn.
• Ein definiertes Verhalten bei Stromrückkehr: Dienste starten automatisch und in der richtigen Reihenfolge.

Muster 6: Updates und Datensicherung für beide Orte

• Updates werden gestaffelt ausgerollt: erst zentral, dann eine Testgruppe, dann alle lokalen Knoten. Jede Version lässt sich zurückrollen.
• Datensicherungen liegen lokal und zentral. Wiederherstellung wird regelmäßig geprobt, nicht nur angenommen.
• Wartungsfenster und Aufräumarbeiten auf lokalen Knoten sind protokolliert und nachvollziehbar.

5. Aus der Praxis: zwei Projekte, ein Prinzip

Nach genau diesen Mustern bauen wir derzeit zwei Anwendungen für das Gesundheitswesen.

Praxissoftware für Physiotherapie

Jede Praxis bekommt einen kleinen, sparsamen Server vor Ort und zusätzlich eine eigene Instanz im Rechenzentrum. Beide laufen aus demselben Container-Image. Im Normalbetrieb arbeitet die Praxis lokal, die Instanz im Rechenzentrum hält den Datenbestand aktuell.

Den Ernstfall haben wir nicht nur auf dem Papier durchgespielt. Im Ausfalltest wurde der Praxisserver absichtlich abgeschaltet. Der Wechsel auf die Instanz im Rechenzentrum erfolgte per Knopf, die Arbeit ging weiter. Die Rückkehr auf den lokalen Betrieb dauerte gut zwei Minuten, ohne Datenverlust.

Order Entry für Laboraufträge

Ein webbasiertes Order Entry, mit dem Praxen Laboraufträge erfassen. Es läuft bereits online. Die Redundanz nach demselben Prinzip, eine führende Datenbank und eine Instanz in Bereitschaft, ist umgesetzt und wird bei jedem Build automatisiert geprüft. Der Server vor Ort ist die nächste Etappe.

Was beide gemeinsam haben

• Ein Image, das zentral und lokal identisch läuft. Es gibt keine Notfallversion, die nie getestet wurde.
• Immer genau eine führende Datenbank. Wer führt, entscheidet ein Mensch, nicht ein nervöser Automatismus.
• Der lokale Betrieb braucht im Ernstfall nichts aus dem Internet.

Der zweite Punkt ist der unbequemste und zugleich der wichtigste. Vollautomatisches Umschalten klingt modern. Bei einer Leitung, die alle zehn Minuten kurz wegbricht, produziert es aber genau das Chaos, das man vermeiden will.

6. TCO neu rechnen: Resilienz gehört in die Gleichung

Die klassische TCO-Rechnung muss nicht verworfen werden. Sie braucht einen zusätzlichen Posten: die erwarteten Kosten von Ausfällen.

Vereinfacht:

Resilienz-TCO = Betriebskosten + (erwartete Ausfallstunden × Kosten pro Ausfallstunde)

Ein lokaler Container-Knoten erhöht die Betriebskosten: Hardware, USV, Pflege, Monitoring. Er senkt aber die zweite Hälfte der Gleichung drastisch, weil ein Leitungsausfall nicht mehr zum Betriebsausfall wird.

Rechenbeispiel mit Platzhalterwerten (zur Veranschaulichung, keine Marktdaten):

Der lokale Knoten lohnt sich, sobald A × S > K. In ruhigen Zeiten mag A klein sein und die Rechnung knapp ausgehen. In einer längeren Krise steigt A, und damit kippt die Rechnung eindeutig. Jeder Betrieb kann diese drei Werte für sich selbst schätzen. Das ist ehrlicher als jede pauschale Branchenzahl.

Wichtig ist auch, was die Rechnung nicht zeigt: Bei Versorgungseinrichtungen hängen am Betrieb Patienten, Termine und Fristen. Diese Folgekosten sind schwer in Euro zu fassen, gehören aber in die Entscheidung.

7. Grenzen und Fallstricke

Ein verteiltes System ist kein Selbstläufer. Wer zentral und lokal betreibt, übernimmt neue Aufgaben:

• Komplexität: Zwei Orte bedeuten zwei Zustände, die überwacht werden müssen. Ohne Monitoring merkt niemand, dass ein lokaler Knoten seit Wochen nicht mehr synchronisiert.
• Synchronisationskonflikte: Konfliktregeln müssen fachlich durchdacht sein, nicht nur technisch. Was bei einer Terminänderung harmlos ist, kann bei einer Abrechnung teuer werden.
• Sicherheit vor Ort: Ein lokaler Knoten ist physisch zugänglich. Verschlüsselte Datenträger, gesperrte Zugänge und eine klare Verantwortlichkeit sind Pflicht, gerade bei sensiblen Daten.
• Datenschutz und Regulatorik: Wo personenbezogene oder Gesundheitsdaten liegen, ist rechtlich relevant. Eine lokale Kopie muss in das Datenschutzkonzept passen.
• Menschliche Prozesse: Der Failover-Knopf nützt nichts, wenn niemand weiß, wann er ihn drücken darf. Notfallabläufe müssen kurz, verständlich und geübt sein.

8. Checkliste für Betreiber

• ☐ Läuft die Anwendung zentral und lokal aus demselben Container-Image?
• ☐ Ist eindeutig festgelegt, welche Datenbank führend ist, und wie die Führung wechselt?
• ☐ Sperrt sich eine Instanz selbst, wenn ihre Rolle unklar ist?
• ☐ Startet der lokale Knoten ohne Internet (Images, Anmeldung, Zeit, DNS, Lizenz)?
• ☐ Werden ausgehende Vorgänge lokal gepuffert und später nachgeholt?
• ☐ Sieht der Nutzer, ob er online, offline oder im Notbetrieb arbeitet?
• ☐ Hängen Server, Router und Switch an einer Notstromversorgung?
• ☐ Starten die Dienste nach Stromrückkehr automatisch in der richtigen Reihenfolge?
• ☐ Gibt es Backups an beiden Orten, und wurde die Wiederherstellung zuletzt geprobt?
• ☐ Sind Updates gestaffelt und zurückrollbar?
• ☐ Kennen die Mitarbeitenden vor Ort den Notfallablauf?

Fazit

TCO hat die Zentralisierung zu Recht vorangetrieben. Die zentrale Webanwendung hat Betrieb, Sicherheit und Kosten für viele Organisationen erst beherrschbar gemacht. Aber die Rechnung hat stillschweigend vorausgesetzt, dass die Infrastruktur dazwischen immer funktioniert.

Unter den Bedingungen einer längeren strukturellen Krise ist diese Voraussetzung nicht mehr gegeben. Wer dann nur zentral betreibt, hat seine Kosten optimiert und seine Verwundbarkeit gleich mit.

Container-Konzepte, die dasselbe System zentral und dezentral betreiben, lösen diesen Widerspruch auf: Im Normalbetrieb profitiert man von der Zentralisierung, im Störfall läuft der Betrieb vor Ort weiter. Mit klaren Rollen, ohne versteckte Abhängigkeiten nach außen und mit sparsamer, notstromfähiger Hardware. Dass das funktioniert, zeigen die Physio-Software und das Labor-Order-Entry schon heute.

Das ist keine Rückkehr in die Vergangenheit. Es ist die nächste Stufe der TCO-Rechnung, eine, die Ausfälle nicht mehr als Ausnahme behandelt, sondern als Kostenposten.

Resilienz ist kein Zusatzmodul. Sie ist eine Architekturentscheidung, und die trifft man vor dem Ausfall, nicht währenddessen.