• Lift‑and‑Shift von Public‑Cloud‑Mustern ohne Air‑Gap‑Plan: Externe Registries, SaaS‑Abhängigkeiten, Managed‑Control‑Planes – alles rote Flaggen.
  • Chatty‑Microservices: 50 interne HTTP‑Hops für einen Domänenvorgang sind im Feld nicht debugbar.
  • Homegrown‑Krypto: Keine Eigenbau‑PKI ohne klaren Lebenszyklus und Audits. Besser wenig, aber korrekt.
  • “Später Security”: SBOMs, Signaturen, Policies nachzurüsten ist teurer und unvollständig. Der Aufwand lohnt sich nur, wenn er ab Tag 1 eingeplant ist.
  • Telemetrie‑Abfluss ohne Klassifizierung: “Wir schicken nur Metriken raus” – bis jemand bemerkt, dass Fehlermeldungen PII enthalten.

Konkrete Startempfehlung ohne Hype

  • Katalogisiere Datenflüsse: Welche Daten müssen bleiben, welche dürfen wohin, in welcher Latenz und mit welchem Schutzbedarf?
  • Definiere das kleinste sinnvolle Plattform‑Backbone: Orchestrierung, Registry, Git‑Mirror, Observability‑Stack, Secrets. Nicht mehr.
  • Wähle Architekturgrenzen entlang der Domäne: modularer Monolith plus 1‑2 isolierte Services, wenn nötig.
  • Baue die Lieferkette: Reproduzierbare Builds, Signaturen, SBOM, Artefakt‑Bündel. Teste einen vollständigen Offline‑Rollout auf einer Sandkasten‑Installation.
  • Übe den Audit‑Fall: Erzeuge einen forensischen Dump, stelle ihn einem Auditor zur Verfügung (synthetische Daten), miss die Zeit bis zur Beantwortung typischer Fragen.

Mini‑Beispiel aus der Praxis

In einer Flotten‑Intelligenz‑Plattform für ein Schienennetz mussten wir Ereignisdaten aus Fahrzeugen mit wochenlangen Offline‑Phasen robust sammeln und später korrelieren. Lösung: Lokaler Event‑Log pro Fahrzeug, kompaktiert und priorisiert; Basis‑Analytik on‑board (Fehlerklassen, einfache Schwellen), Deep‑Dive‑Analysen on‑prem beim Andocken; Updates für die On‑board‑Komponenten als signierte Bundles im Wartungsfenster. Das zentrale System blieb bewusst monolithisch‑modular (Ingestion, Regeln, UI), nur die GPU‑gestützte Inferenz lief als separater, begrenzter Service. Ergebnis: geringere Betriebslast und bessere Vorhersehbarkeit als mit einem Microservice‑Zoo.

In einer Trainingsplattform für die Luftfahrt stand Auditierbarkeit im Vordergrund: Jede Trainingssitzung, jede Bewertungsentscheidung musste rekonstruierbar sein. Wir haben eine Event‑Sourcing‑Schicht eingeführt, deren Snapshots regelmäßig air‑gapped gesichert werden; Identität wurde strikt über das Unternehmens‑IAM gebunden, Workload‑Identität separat verwaltet. Dadurch konnten Audits ohne Spezialabfragen bedient werden – die Domäne sprach in den Ereignissen für sich.

Fazit

“Cloud‑native” ist kein Ort, sondern eine Arbeitsweise. In regulierten Branchen gewinnt diejenige Architektur, die Cloud‑Ergonomie mit on‑prem‑Souveränität verbindet: kleine, stabile Plattformkerne; saubere Lieferketten; asynchrone Kopplung; bewusste Grenzen; und ein Betriebsmodell, das auch ohne Internet hält. Wer so plant, liefert schneller, auditierbarer und robuster – ohne einen Byte an die falsche Stelle zu schicken.

FAQ

Frage: Brauche ich zwingend Kubernetes on‑prem, um “cloud‑native” zu sein?
Antwort: Nein. Was Sie brauchen, sind deklarative Deployments, Wiederholbarkeit und Isolierung. Kubernetes ist oft ein guter Weg dorthin – vor allem, wenn Air‑Gap‑Fähigkeiten, Offline‑Registries und stabile Upgrades verfügbar sind. Für kleine, eindeutig geschnittene Systeme kann ein Prozess‑Supervisor plus Container‑Runtime ausreichen. Entscheidend ist, dass Sie Builds, Releases und Rollbacks reproduzierbar beherrschen.

Frage: Wie integriere ich Identität zwischen Unternehmens‑IAM und Workloads?
Antwort: Trennen Sie menschliche und Maschinenidentität. Menschen authentifizieren sich über das vorhandene IAM (AD/LDAP/OIDC), autorisieren über rollenbasierte Policies. Workloads erhalten kurzlebige, drehbare Identitäten (z. B. mTLS‑Zertifikate), die an die Runtime‑Eigenschaften gebunden sind. Vermeiden Sie langlebige statische Secrets in ConfigMaps. Rotationspfade und Ablaufdaten sind Teil des Deployments, nicht des Handbetriebs.

Frage: Wie aktualisieren wir Modelle und KI‑Komponenten in einer Offline‑Umgebung?
Antwort: Behandeln Sie Modelle wie Software‑Artefakte: Versioniert, signiert, mit SBOM und Provenance. Schneiden Sie Releases als vollständige Bundles (Modell, Tokenizer, Konfiguration, ggf. Quantisierung) und verteilen Sie sie über den gleichen, geprüften Artefakt‑Pfad wie Software. Evaluieren Sie Modelle offline gegen kuratierte Testsets, bevor sie in Produktion gehen. Telemetrie zur Inferenzqualität bleibt on‑prem und fließt nur nach definierten Policies ab.

Frage: Wann lohnt sich die Aufteilung in Microservices in regulierten Netzen?
Antwort: Wenn Sie harte Isolation benötigen, unterschiedliche Skalierungsprofile haben oder verschiedene Compliance‑Zonen trennen müssen. Starten Sie modular‑monolithisch und extrahieren Sie gezielt dort, wo Messwerte (Latenz, Ausfall‑Impact, Team‑Ownership) eine Trennung rechtfertigen. Eine breite Microservice‑Landschaft erhöht in on‑prem‑Netzen die Betriebsrisiken und Debug‑Komplexität.

Frage: Wie plane ich für einen Lebenszyklus von zehn Jahren und länger?
Antwort: Standardisieren Sie auf wenige, gut beherrschte Bausteine mit klaren Upgrade‑Pfaden. Vermeiden Sie exotische Abhängigkeiten. Etablieren Sie eine reproduzierbare Build‑/Release‑Kette und dokumentieren Sie Runbooks. Testen Sie regelmäßig DR‑Szenarien. Planen Sie Hardware‑Headroom ein und definieren Sie eine Roadmap für Betriebssystem‑ und Plattform‑Upgrades, die Ihre Applikation nicht jedes Mal zerlegt. Entscheidend ist, dass Sie Austausch‑ und Migrationskosten früh antizipieren und Reversibilität bewusst einbauen.