Kernmuster:

  • Supply‑Chain im Koffer:

  • Vollständige Spiegel der Build‑Werkzeuge, Abhängigkeiten und Basis‑Images.

  • Deterministische Builds, SBOMs, Signaturen und Provenance‑Metadaten gehören zum Transfer‑Paket.

  • Transfer‑Prozess:

  • Physische Medien mit Ketten‑von‑Obhut‑Protokoll.

  • In der Zielzone erneute Verifikation, Staging, dann gestaffelter Rollout (Canary, Blue/Green).

  • Betriebsautonomie:

  • Lizenz‑ und Aktivierungsmechanismen dürfen keine Online‑Phone‑Homes erfordern.

  • Wissenspakete (Runbooks, Troubleshooting‑Flows, Testsuiten) gehören mit ins System.

  • Notfall‑Pfad:

  • “Break‑glass”‑Konten sind vorhanden, aber dokumentiert und geauditet.

  • Offline‑Backups plus regelmäßige Restore‑Proben sind Pflicht, nicht Kür.

Praxis‑Hinweise:

  • Wähle Technologien, die Air‑Gap ernst nehmen: Offline‑Docs, reproduzierbare Upgrades, keine versteckten Telemetrie‑Abhängigkeiten.

  • Plane Hardware‑Sizing konservativ. In einer Air‑Gap‑Welt gibt es keine elastische Skalierung “bei Bedarf”.

Monolith vs. Microservices im On‑Prem‑Kontext: weniger ist oft mehr

Die Frage ist hier nicht ideologisch, sondern operativ: Welches Architekturmodell minimiert Komplexität bei akzeptablem Risiko?

Beobachtung aus Projekten:

  • Ein modularer Monolith mit klaren internen Grenzen schlägt in vielen on‑prem‑Szenarien ein Geflecht aus 30 Microservices. Gründe:

  • Netzwerk ist die teuerste und fragilste Ressource vor Ort. Jeder Hop ist ein potenzieller Ausfall- und Debug‑Punkt.

  • Teamgrößen: Drei bis fünf Entwickler plus ein Betriebsingenieur skalieren eine Microservice‑Landschaft operativ nur mit erheblichem Tooling‑ und Prozess‑Overhead.

  • Update‑Fenster sind knapp. Ein Paket, ein Datenbank‑Migrationsschritt, ein Rollback‑Pfad ist berechenbarer als viele kleine Deployments.

Wann Services rechtfertigt sind:

  • Harte Isolation notwendig (z. B. sicherheitskritischer Kern getrennt von Analysefunktion).

  • Unterschiedliche Skalierungscharakteristika (z. B. Inferenz auf GPU‑Nodes vs. reine UI/Reporting).

  • Unterschiedliche Lebenszyklen oder Compliance‑Zonen.

Praktisches Muster:

  • Starte mit einem modularen Monolithen, der entlang klarer Domänenzuschnitte intern Ports/Adapter nutzt.

  • Extrahiere einzelne Services erst, wenn eine messbare Belastung oder ein Risiko dies rechtfertigt (z. B. 95‑Perzentil‑Latenz eines GPU‑Inference‑Pfads, die den Rest ausbremst).

Event‑Driven in Echtzeitumgebungen

Asynchrone Kopplung ist in regulierten Netzen oft der größte Hebel, um Robustheit zu erreichen:

  • Command/Query synchron, State/Ereignisse asynchron.

  • Idempotente Konsumenten, Re‑Delivery‑tolerant.

  • Eindeutige Schemas mit semantischer Versionierung; keine “magischen” JSON‑Felder ohne Vertrag.

  • In intermittenten Netzen: Replikations‑Links, die bewusst volumetrische Limits und Prioritäten kennen (z. B. sicherheitsrelevante Alarme vor “nice‑to‑have” Telemetrie).

AI/ML und LLM‑Workloads on‑prem: Besonderheiten, die oft vergessen werden

  • GPUs als “First‑Class Citizens”:
  • Scheduler, der GPU‑Ressourcen strikt quotiert.
  • Keine “Pets”‑GPUs mit manuell installierten Treibern; Treiber/Kernels sind Teil des reproduzierbaren Systemzustands.
  • Modell‑Governance:
  • Modelle, Prompts, Trainings‑/Testdaten sind Artefakte mit Version, Signatur, Herkunft.
  • Inferenz‑Pfad protokolliert nachvollziehbar: Eingaben (so weit rechtlich zulässig), Modellversion, Konfiguration, Antwort, Metriken. Ohne diese Kette gibt es keine Auditierbarkeit.
  • Datenhoheit:
  • Vektor‑Datenbanken und Embeddings lokal, ebenso RAG‑Korpora. Ausleitung nur nach expliziten Policies, niemals “lernt nebenbei” aus Produktionsdaten.
  • Offline‑Updates:
  • Modelle werden als Bundles verteilt (inkl. Tokenizer, Konfiguration, ggf. Quantisierung). Keine punktuellen “pip install transformers X.Y” in Produktion.
  • Safety‑Net:
  • Vor Ausrollen: Offline‑Eval mit kuratierten Testsets und Negativbeispielen. On‑Prem muss dieser Schritt automatisiert reproduzierbar sein.
  • Agenten‑Governance:
  • Wenn Agenten Tools ausführen dürfen: restriktive Tool‑Whitelists, Simulation/Sandbox, Dry‑Run‑Modus, und auswertbare Decision‑Logs.

Sicherheit und Compliance, pragmatisch integriert

  • Lieferkette:
  • Reproduzierbare Builds mit signierten Artefakten.
  • SBOMs pro Build, in der Plattform verfügbar. Nicht aus Compliance‑Gründen, sondern als operatives Debug‑Werkzeug.
  • Policies als Code:
  • Deployments passieren Gatekeeper, die einfache Fragen hart beantworten: Darf dieses Image in diese Zone? Sind Secrets referenziert, nicht eingebettet? Stimmt die Workload‑Identität?
  • Secrets:
  • Kurzlebig, rotierbar, nie als Klartext in Artefakten. Wo möglich, Nutzen von Hardware‑gestützten Schlüsseln.
  • Netzwerk:
  • “Default deny” intern, explizite Freigaben per ServiceIntent. Keine impliziten Ost‑West‑Backdoors.
  • Backups/DR:
  • WORM‑fähige Sicherungen für kritische Daten.
  • Geprobte, dokumentierte Restore‑Prozesse. Ein Backup zählt erst, wenn der Restore nachweislich funktioniert hat.

Build‑Run‑Own: Betriebsmodell, das in der Realität hält

  • Geteilte Verantwortung klar schneiden:
  • Hersteller/Plattformteam: Plattform, Toolchain, CI/CD, Baseline‑Security, Observability‑Rahmen.
  • Betrieb vor Ort: Hardware, Netzwerk, Zertifikats‑/Nutzer‑Lifecycle, Wartungsfenster, Notfallprozeduren.
  • Runbooks als code‑nahe Dokumente:
  • Start/Stop‑Sequenzen, Health‑Checks, Log‑“Landkarten”, KPIs, Eskalationspfade.
  • Change‑Fenster diszipliniert nutzen:
  • Bündeln statt Dauerfeuer. Vorab‑Smoke‑Tests in Staging‑Zone, Canary am Rand, dann Breitenrollout.
  • Support ohne Internet:
  • Redigierte Support‑Bundles, die sensible Daten automatisiert ausschließen, aber Diagnosen ermöglichen.
  • “Maintenance Mode”, der gezielt Telemetrie erhöht, ohne Funktion zu beeinträchtigen.

Kosten- und Beschaffungsrealität

  • TCO ehrlich rechnen:
  • Hardware‑Zyklen, Energie, Raum, Ersatzteile.
  • Interne Betriebszeit (Monitoring, Patching, Audits).
  • Lizenzen, die On‑Prem‑ und Offline‑Nutzung fair erlauben.
  • Skalierung mit Augenmaß:
  • Lieber 20% Luft bei CPUs/GPUs einkalkulieren, als später hektisch erweitern zu müssen, wenn Beschaffung 6 Monate dauert.
  • Komponentenvielfalt begrenzen:
  • Jede zusätzliche Plattformkomponente kostet Betriebsenergie. “Benötigen wir das wirklich on‑prem?” ist die wichtigste Frage.

Anti‑Patterns, die wir konsequent vermeiden