Server-Architekturoptionen

Einordnung

Dieser Artikel untersucht mögliche Architekturen für die Server-Komponenten der Einsatzsoftware.

Ziel ist es, den Lösungsraum auf der Serverseite systematisch zu beschreiben und dabei diejenigen Eigenschaften herauszuarbeiten, die für spätere Architekturentscheidungen relevant sind.

Die Betrachtung erfolgt unabhängig von der späteren Programmiersprache. Im Vordergrund stehen zunächst Betriebsmodell, Robustheit, Offline-Fähigkeit, Wartbarkeit und Eignung für die definierten Anwendungsszenarien.

Ausgangslage

Die Einsatzsoftware muss in sehr unterschiedlichen Umgebungen betrieben werden können.

Dazu gehören insbesondere:

lokale Systeme in Fahrzeugen
lokale Systeme in Führungsstellen
zentrale Systeme in Lage- und Koordinierungsstellen
serverseitige Systeme in Rechenzentrums- oder Behördenumgebungen

Dabei ist zu berücksichtigen, dass Netzverbindungen im Einsatz nicht dauerhaft verfügbar sein müssen. Die Serverarchitektur darf daher nicht ausschließlich unter der Annahme eines stabilen und breitbandigen Netzes entworfen werden.

Die Anforderungen an den Betrieb ohne durchgehende Netzverbindung werden im Artikel Netzausfall näher beschrieben.

Grundsätzliche Aufgaben von Server-Komponenten

Server-Komponenten können in der Einsatzsoftware unterschiedliche Aufgaben übernehmen.

Dazu gehören beispielsweise:

Bereitstellung gemeinsamer Datenbestände
Synchronisation zwischen mehreren Arbeitsplätzen
zentrale Benutzer- und Rechteverwaltung
Bereitstellung von Schnittstellen
Aggregation und Auswertung von Daten
Versorgung von Lage- und Visualisierungssystemen

Nicht jede dieser Aufgaben muss in jeder Betriebssituation zentralisiert sein.

Gerade im Einsatzkontext ist zu prüfen, welche Funktionen zwingend einen Server benötigen und welche Funktionen notfalls lokal auf einzelnen Systemen weiterlaufen können.

Architekturoptionen

Im Folgenden werden die wesentlichen Server-Architekturoptionen beschrieben.

Zentrale Serverarchitektur

Bei einer zentralen Serverarchitektur werden die wesentlichen Server-Komponenten an einem zentralen Ort betrieben.

Typische Merkmale sind:

zentrale Datenhaltung
zentrale Benutzerverwaltung
zentrale APIs
einheitlicher Systemzustand

Vorteile:

einfache Administration
klare Zuständigkeiten
gute Kontrollierbarkeit
einfache Datensicherung
einheitliche Updates

Nachteile:

hohe Abhängigkeit von Netzverbindungen
zentrale Ausfallwirkung
im Einsatz nur eingeschränkt robust
bei Netzausfall sinkt die Nutzbarkeit stark

Eine rein zentrale Serverarchitektur ist daher für den Katastrophenschutz allein nicht ausreichend.

Lokale Serverarchitektur

Bei einer lokalen Serverarchitektur werden Server-Komponenten direkt in Fahrzeugen, Führungsstellen oder anderen Einsatzbereichen betrieben.

Dies kann beispielsweise auf einem Laptop, Mini-PC oder einem anderen lokalen System geschehen.

Typische Merkmale sind:

lokale Datenhaltung
lokale APIs
lokale Benutzeroberfläche
Betrieb ohne externe Infrastruktur möglich

Vorteile:

sehr gute Offline-Fähigkeit
geringe Abhängigkeit von externen Netzen
hohe Einsatzrobustheit
gute Beherrschbarkeit im kleinen Rahmen

Nachteile:

verteilte Administrationsaufwände
erschwerte zentrale Aktualisierung
Datenabgleich zwischen mehreren Standorten notwendig
höhere Anforderungen an Synchronisationsmechanismen

Eine rein lokale Architektur ist robust, skaliert aber organisatorisch nur begrenzt.

Föderierte Serverarchitektur

Bei einer föderierten Architektur existieren mehrere eigenständige Server-Instanzen, die jeweils lokal arbeitsfähig sind, aber bei vorhandener Verbindung miteinander Daten austauschen können.

Beispiele:

ein lokaler Server im Fahrzeug
ein lokaler Server in einer Führungsstelle
ein zentraler Server für übergreifende Lagen

Typische Merkmale sind:

lokale Autarkie
verteilte Datenhaltung
kontrollierter Datenaustausch
mehrere Betriebszustände möglich

Vorteile:

hohe Robustheit gegen Netzausfälle
gute Anpassung an reale Einsatzlagen
schrittweise Skalierbarkeit
Kombination aus lokaler Arbeitsfähigkeit und zentraler Zusammenführung

Nachteile:

höhere Komplexität
klare Regeln für Datenabgleich erforderlich
aufwändigere Fehleranalyse
höhere Anforderungen an Versionierung und Konfliktbehandlung

Für die im Projekt beschriebenen Einsatzszenarien ist diese Architektur grundsätzlich besonders naheliegend.

Rechenzentrumsorientierte On-Premise-Architektur

Bei dieser Variante werden zentrale Server in einer Behördennahmen oder organisationsinternen Umgebung betrieben, also nicht in einer öffentlichen Cloud, sondern auf eigener oder kontrollierter Infrastruktur.

Typische Merkmale sind:

Betrieb auf eigenen Servern oder virtuellen Maschinen
Kontrolle über Datenhaltung und Netzsegmente
Integration in vorhandene Verwaltungs- und Sicherheitsstrukturen

Vorteile:

gute Kontrollierbarkeit
hohe Akzeptanz in Behördenumgebungen
Integration in bestehende Prozesse möglich
kein Zwang zu externen Cloud-Diensten

Nachteile:

ohne ergänzende lokale Komponenten nicht ausreichend einsatzrobust
zentrale Infrastruktur bleibt ausfallkritisch
zusätzlicher Betriebsaufwand

Diese Variante ist für zentrale Komponenten sinnvoll, reicht allein für den Einsatzbetrieb aber nicht aus.

Cloud-zentrierte Architektur

Bei einer cloud-zentrierten Architektur befinden sich die wesentlichen Server-Komponenten in externen oder zentral bereitgestellten Cloud-Umgebungen.

Typische Merkmale sind:

zentrale Bereitstellung über Internet-Zugriff
elastische Skalierung
geringe lokale Infrastruktur

Vorteile:

einfache Skalierung
schneller zentraler Rollout
geringe lokale Betriebsaufwände

Nachteile:

hohe Abhängigkeit von Internet und Netzinfrastruktur
im Katastrophenschutz nur eingeschränkt robust
kritisch bei längerem Netzausfall
zusätzliche Diskussionen zu Datenschutz, Kontrolle und Abhängigkeiten

Für einsatzkritische Kernfunktionen ist eine rein cloud-zentrierte Architektur daher nicht geeignet.

Containerbasierte Serverarchitektur

Container beschreiben keine eigene fachliche Architektur, sondern eine technische Form des Betriebs.

Im gegebenen Projektkontext sind insbesondere folgende Varianten relevant:

Docker
Podman

Vorteile:

reproduzierbare Deployments
klare Trennung von Komponenten
gute Portabilität
vereinfachte Wartung

Nachteile:

zusätzlicher Betriebs-Layer
höhere technische Komplexität
nicht jeder lokale Einsatzserver muss zwingend containerisiert betrieben werden

Container können sinnvoll sein, sind aber keine eigenständige Antwort auf die fachliche Architekturfrage.

Microservices

Microservices teilen ein System in viele kleine, eigenständig deploybare Dienste auf.

Vorteile:

technische Entkopplung
unabhängige Skalierung einzelner Dienste
klare fachliche Trennung möglich

Nachteile:

hoher Betriebsaufwand
verteilte Fehlersuche
höhere Anforderungen an Monitoring, Logging und Deployment
für kleine bis mittlere Systeme oft unnötig komplex

Im vorliegenden Kontext ist besondere Vorsicht geboten. Eine zu frühe Aufteilung in viele Einzelkomponenten erhöht die Komplexität stark, ohne zwingend einen praktischen Nutzen zu bringen.

Modularer Monolith

Ein modularer Monolith ist ein zusammenhängendes System mit klar getrennten Modulen, das jedoch als einheitliche Anwendung betrieben wird.

Typische Merkmale sind:

ein gemeinsamer Deployable
klare Modulgrenzen innerhalb des Systems
geringe Betriebs- und Integrationskomplexität

Vorteile:

gute Wartbarkeit
geringerer Betriebsaufwand als Microservices
einfache lokale Installation
gut geeignet für schrittweisen Ausbau

Nachteile:

spätere Aufteilung in getrennte Dienste muss bewusst vorbereitet werden
falsche Modulgrenzen können langfristig Probleme verursachen

Für das hier betrachtete Projekt ist ein modularer Monolith serverseitig grundsätzlich sehr attraktiv.

Architekturfragen mit besonderer Relevanz

Unabhängig von der konkreten Serverarchitektur sind mehrere Fragen zwingend vorab zu klären.

Lokale Betriebsfähigkeit

Es muss geklärt werden, welche Server-Funktionen lokal im Fahrzeug oder in einer Führungsstelle lauffähig sein müssen.

Dies betrifft insbesondere:

lokale Datenhaltung
lokale Synchronisationsfunktionen
lokale Visualisierung
lokale Benutzeroberflächen

Zentrale Zusammenführung

Es muss geprüft werden, welche Funktionen zwingend zentral gebündelt werden sollen.

Dies kann insbesondere betreffen:

überregionale Lagebilder
organisationsweite Benutzerverwaltung
zentrale Berichte
organisationsweite Schnittstellen

Betriebsgrenzen

Es ist zu definieren, ab wann eine lokale Instanz genügt und ab wann eine zentrale Instanz benötigt wird.

Diese Abgrenzung ist wichtig, um spätere Diskussionen über unnötige Zentralisierung oder unnötige Dezentralisierung zu vermeiden.

Vorläufige Bewertung

Für die beschriebenen Einsatzszenarien lassen sich bereits mehrere Aussagen treffen.

Erstens ist eine rein zentrale oder rein cloudbasierte Serverarchitektur für einsatzkritische Funktionen nicht ausreichend, da sie zu stark von stabilen Netzverbindungen abhängt.

Zweitens ist eine rein lokale Architektur zwar robust, führt aber bei größeren Lagen zu erhöhtem Administrations- und Abstimmungsaufwand.

Drittens spricht vieles für eine Architektur, die lokale Arbeitsfähigkeit mit zentraler Zusammenführung kombiniert.

Viertens ist auf technischer Ebene ein modularer Monolith im gegebenen Projektkontext deutlich naheliegender als eine frühe Microservice-Architektur.

Schlussfolgerung

Für die Einsatzsoftware kommen mehrere Server-Architekturoptionen in Betracht.

Aus heutiger Sicht erscheinen insbesondere folgende Kombinationen sinnvoll:

lokale Server-Komponenten für den Einsatzbetrieb
zentrale Server-Komponenten für organisationsweite Funktionen
containerbasierter Betrieb, wo er organisatorisch sinnvoll ist
modularer Monolith statt früher Zerlegung in viele kleine Dienste

Die wahrscheinlich sinnvollste Richtung ist damit keine rein zentrale und keine rein lokale Architektur, sondern ein föderierter Ansatz mit lokal arbeitsfähigen Instanzen und zentralen Zusammenführungsmöglichkeiten.

Die genaue Ausgestaltung dieser Architektur ist in späteren Design-Schritten weiter zu präzisieren.