Auch wenn dieses Stück nicht primär „Monolith vs. Microservices“ adressiert: In regulierten On-Prem-Umgebungen gewinnt häufig die einfachere Lösung. Wenn Ihr System aus zwei bis vier klar abgegrenzten Domänen besteht, ist ein modularer Monolith oder wenige gut geschnittene Services leichter zertifizierbar, testbarer und betrieblich günstiger. Ein Zoo aus Dutzenden Services kostet Sie Identity-/PKI-/Observability-Multiplikatoren, die Sie on-prem selbst tragen müssen. Verteilen Sie nur, wo es technische Gründe gibt (Latenzdomäne, Skalierungsdomäne, Isolationsgründe) – nicht, weil es „state of the art“ klingt.

Typische Stolpersteine aus der Praxis

  • Cloud-Konzepte 1:1 übernehmen: Ein S3-Endpoint in der Cloud ist kein S3-Endpoint on-prem – Latenzen, Konsistenzannahmen, Auth-Mechanismen unterscheiden sich. Testen Sie Flows mit realistischen Ausfallszenarien.
  • „Wir bauen später Governance ein“: Ohne signierte Artefakte und deklarative Zustände werden Hotfixes zur Regel. Auditierbarkeit leidet und Sicherheitslücken bleiben unbemerkt.
  • Service Mesh früh einführen: In kleinen Umgebungen erschlägt die Komplexität den Nutzen. Fangen Sie mit mTLS, PKI und sauberem Ingress/Egress an.
  • Zu große Logs, zu kleine Retention: On-prem-Speicher ist nicht unendlich. Wählen Sie Metriken/Traces bewusst, definieren Sie Sampling und Korrelation – weniger, aber aussagekräftiger.
  • Keine klare Trennung zwischen IT und OT: Unterschiedliche Change-Kulturen und Wartungsfenster müssen architektonisch berücksichtigt werden. Ein gemeinsames Deploy-Fenster erzwingen zu wollen, endet meist im Stillstand.

Was „Souveränität ermöglicht Intelligenz“ konkret heißt

Souveränität ist keine Ideologie, sondern eine Betriebsbedingung: Wer seine Softwarestände, Modelle und Datenflüsse kontrolliert, kann experimentieren, ausrollen, zurückrollen – und lernen. In der Cloud ist das oft durch Anbieter-Services „mitgeliefert“. On-prem heißt es: selbst bauen, aber gezielt. Wer Governance, Observability und Reproduzierbarkeit als Kernanforderungen behandelt, holt sich die Entwicklungsgeschwindigkeit der Cloud ins eigene Rechenzentrum oder Werk – ohne die Hoheit über Daten und Betrieb zu verlieren.

Pragmatischer Fahrplan für den Aufbau

1) Minimal Viable Platform definieren

  • Ziele: Private Registry, GitOps-Controller, interner IdP, Observability-Basics.

  • Ergebnis: Ein Standort kann deklarativ in Betrieb gehen, Artefakte sind signiert, Logs/Metriken sind sichtbar.

2) Artefaktkette härten

  • SBOMs, Signaturen, Promotionspfade; Air-Gap-Transportweg mit Verifikation.

3) Domänenschnitt schärfen

  • Welche Services sind echt unabhängig? Welche müssen ko-lokal bleiben? Latenz- und Isolationsgründe dokumentieren.

4) Betriebsrunbooks und DR testen

  • Regelmäßige Restore-Übungen; Notfallmodus definieren (z. B. „Inferenz-only“ wenn zentrale Policies nicht erreichbar).

5) Schrittweise Automatisierung

  • Von manueller Freigabe zu Policy-Driven Approvals; von statischen Dashboards zu SLO-basierten Alerts.

FAQ

Wie viel „Kubernetes“ braucht man on-prem?
Die ehrlichste Antwort: So viel, wie Ihre Teams sicher betreiben können. Wenn Sie Elastizität, Rolling-Updates und Workload-Isolation brauchen, ist ein Orchestrator sinnvoll. Wenn Ihr System aus wenigen Diensten mit harten Latenzanforderungen besteht, gewinnt oft ein schlankerer Stack. Entscheidend ist ein deterministischer, wiederholbarer Betrieb – nicht das konkrete Tool.

Wie gehen Updates in einer air-gapped Umgebung?
Updates werden außerhalb des Standorts gebaut, gescannt und signiert. Die signierten Artefakte (Images, Charts, Policies) werden über einen gesicherten Transportweg (z. B. physische Medien, dedizierter Pull-Proxy) in den Standort gebracht. Vor Ort verifiziert ein GitOps-Controller die Signaturen und setzt den deklarierten Stand um. „Latest“-Tags und ad-hoc-Pulls sind tabu.

Wie stelle ich Auditierbarkeit sicher?
Jede Änderung ist eine Commit- und Release-Entscheidung. Bewahren Sie SBOMs, Signaturen, Promotionsprotokolle und unveränderliche Logs auf. Versionieren Sie auch Konfigurationen und Policies. Für ML/AI zusätzlich: Modellkarten mit Trainingsdatenherkunft, Evaluationsmetriken und Freigabeprotokollen. Audit-Artefakte gehören in WORM-Speicher mit langfristiger Aufbewahrung.

Brauche ich ein Service Mesh für mTLS und Policies?
Nicht zwingend. Für viele Umgebungen reicht eine solide PKI, mTLS auf Transportebene, klare Ingress-/Egress-Kontrollen und autorisierte Service-Identitäten. Ein Mesh lohnt sich, wenn Sie komplexe Traffic-Shapes, teamübergreifende SLOs oder dynamische, feingranulare Policies im Datenpfad brauchen – und die Betriebskompetenz dafür vorhanden ist.

Wie teste ich Skalierung und Latenzen ohne Cloud?
Mit synthetischer Last, realen Artefakten und repräsentativer Hardware. Simulieren Sie Netzunterbrechungen, begrenzte Bandbreiten und degradierte Storage-Performance. Für Latenzpfade (z. B. Kamera → Inferenz → Aktor) bauen Sie reproduzierbare Benchmarks und messen End-to-End, nicht nur CPU/GPU-Auslastung. Skalierungstest heißt hier oft: mehrere Standorte, nicht nur mehr Pods.

Schlussgedanke

„Cloud-native“ ist ein Arbeitsstil und ein Architekturprinzip – kein Synonym für Public Cloud. In regulierten Branchen gewinnt, wer Cloud-Prinzipien pragmatisch adaptiert: deklarativer Betrieb, automatisierte Artefaktkette, reproduzierbare Umgebungen, starke Identitäten und Telemetrie, die Antworten liefert. Dann wird Souveränität nicht zum Bremser, sondern zum Enabler intelligenter Systeme – in der Fertigungshalle, im Zugdepot, im Cockpit oder im Vermessungsfahrzeug.