Muster 6: Getrennte Ebenen – Steuerungsebene vs. Datenebene

  • Ziel: Das System bleibt bedienbar, auch wenn Teile der Datenverarbeitung ausfallen. Sicherheitspolicies liegen nicht dort, wo die Nutzdaten fließen.
  • Umsetzung:
  • Steuerungsebene: Identitätsdienste, GitOps-Controller, Registries, Audit, Policy-Engines.
  • Datenebene: Verarbeitungspipelines, Datenbanken, Inferenzdienste.
  • Strikte Isolierung (Netzwerk, Rechte, Schlüsselmaterial). Ein Ausfall der Datenebene darf Steuerung nicht behindern – und umgekehrt.
  • Trade-off:
  • Vorteile: Fehler entkoppeln, klarere Verantwortlichkeiten.
  • Kosten: Zwei Infrastrukturen logisch denken und betreiben – erfordert Disziplin.

Muster 7: Topologien für Edge und Multi-Site

  • Ziel: Die Funktion liegt dort, wo Datenentstehung, Latenz- und Souveränitätsanforderung es verlangen.
  • Umsetzung:
  • Edge-Knoten nahe der Maschine: Vorverarbeitung, schnelle Entscheidungen, Pufferung.
  • Standort-Cluster: Aggregation, Training-Light, zentrale Dienste für den Standort.
  • Zentrale: Modellregistrierung, langfristige Analytik, übergreifende Fleet-Intelligence. Synchronisation asynchron, robust gegen Ausfälle.
  • Entscheidungsheuristik:
  • Latenz kritisch und Daten sensibel => Edge.
  • Datenvolumen hoch, aber Entscheidung unkritisch => Batch am Standort.
  • Korrelation über Flotte erforderlich, Daten pseudonymisierbar => Zentrale, aber nur mit strikter Anonymisierung.

Muster 8: API-Design für Langlebigkeit

  • Ziel: Evolvierbare Schnittstellen, die 10+ Jahre überleben – trotz Technologie- und Teamwechseln.
  • Umsetzung:
  • Klare Domänenschnitte, wenig „Feinkrümel“-Services. Events als stabile Verträge.
  • Versionierung mit expliziten Deprecation-Zeitplänen. Backwards-kompatible Änderungen bevorzugen.
  • Strukturelle Typen, additive Felder, explizite Defaults. Fehler als Teil des Protokolls, nicht als Exceptions über Netzwerk verschickt.
  • Für industrielle Geräte: Protokolle, die auch mit schlechter Verbindung funktionieren (z. B. binär, gepuffert, mit Sequenznummern).
  • Trade-off:
  • Vorteile: Weniger Kopplung, weniger Updates auf der Fläche.
  • Kosten: Höhere Disziplin in Schemata und Kompatibilitätstests.

Muster 9: Ressourcenmanagement ohne elastische Cloud

  • Ziel: Die Plattform reagiert auf Überlast kontrolliert, ohne „unendlich“ skalieren zu können.
  • Umsetzung:
  • Backpressure überall: Queues und Timeouts begrenzen Schaden. Priorisierung für echtzeitkritische Pfade.
  • Kapazitätsplanung basierend auf Lastprofilen; Reservierungen für kritische Workloads (z. B. GPU-Slots).
  • Degradationsmodi: Statt Ausfall lieber reduzierte Qualität (z. B. weniger Frames pro Sekunde, vereinfachte Modelle).
  • Trade-off:
  • Vorteile: Vorhersehbares Verhalten, auch in Störungen.
  • Kosten: Mehr Engineering für Lasttests und „Chaos“-Szenarien.

On-Premise heißt nicht „kein Kubernetes“ – aber „Kubernetes reicht nicht“

Container-Orchestrierung löst Workload-Isolation und Deployment-Standardisierung gut. Aber viele gescheiterte On-Prem-Projekte hatten die Illusion, dass ein Orchestrator alles löst. In regulierten Umgebungen sind mindestens ebenso wichtig:

  • PKI, Identitäten, Signaturen
  • Artefakt-Registries im Kundennetz
  • GitOps und Freigabeworkflows
  • Netzwerksegmente und deterministische Routen
  • Monitoring und Telemetrielake on-prem
  • Offline-Update-Prozesse und reproduzierbare Builds

Wann kein Orchestrator? Kleine, deterministische Systeme mit 2–3 Prozessen pro Host, harte Echtzeitnahe Anforderungen, begrenzte Operatoren. Dort reichen Prozesssupervisoren, statische Konfigurationen und ein robuster Update-Mechanismus. Jede zusätzliche Abstraktion muss sich rechtfertigen.

Microservices vs. Monolith: Teamgröße und Fehlerdomänen

  • Monolith gewinnt, wenn:
  • Ein kleines, erfahrenes Team eine klar definierte Domäne abbildet.
  • Deployment-Fenster eng sind und jede verteilte Transaktion teuer wird.
  • Die Observability- und Netzwerkkompetenz im Betrieb begrenzt ist.
  • Microservices gewinnen, wenn:
  • Verschiedene Lebenszyklen und Skalierungsprofile existieren (z. B. ML-Inferenz vs. Batch-Import).
  • Ein Domänenschnitt technisch und organisatorisch sauber getrennt ist.
  • Events als Integrationsverträge etabliert sind und Idempotenz gelebt wird.

Minimal-Referenzarchitektur für eine souveräne Plattform

Zielbild auf einem Standort, erweiterbar auf Multi-Site:

  • Perimeter und Zonen:
  • DMZ für Inbound/Outbound-Transfer, Malware-Scan, Proxys.
  • Produktionszone: Cluster für Anwendungs- und Datenebene.
  • Steuerungszone: Git-Server, GitOps-Controller, CA, Artefakt-Registry, Observability.
  • Lieferkette:
  • Dev-Zone (getrennt): Code -> CI -> signierte Artefakte + SBOM -> kontrollierter Transfer -> Registry on-prem -> Deployment via GitOps.
  • Datenpfad:
  • Ingestion-Services empfangen Maschinendaten über robuste Protokolle.
  • Message-Backbone mit persistenten Queues. Verarbeitungspipelines abonnieren Events.
  • Objektspeicher (S3-kompatibel) für große Binärdaten, referenziert aus Events.
  • Analytics/ML-Schicht mit Feature-Store on-prem, Modell-Registry, Batch- und Streaming-Jobs.
  • Sicherheitsdienste:
  • Private PKI, mTLS überall, rollenbasierte Policies.
  • Secrets-Management mit kurzlebigen Tokens.
  • Observability:
  • Zentrales Telemetrie-Backend, Log-/Metrik-/Trace-Ingestion, Dashboards, Alerting.
  • Audit-Log mit Unveränderlichkeitsgarantien (append-only Speicher).
  • Betriebsprozesse:
  • Gestaffelte Rollouts, Change-Kalender, automatisierte Tests und Smoke-Checks.
  • Regelmäßige DR-Übungen: Backup/Restore, CA-Rollover, Registry-Recovery.

LLM- und Agentenkomponenten on-prem betreiben

In einigen Branchen sind Sprach- und Vision-Modelle inzwischen Teil der Lösung (z. B. Dokumentenklassifikation, Fertigungsinspektion, Wissensassistenten für Techniker). Die zusätzlichen Anforderungen:

  • Datenlinie und Governance:
  • Prompt, Kontext, Auswahl der Modelle und Ausgaben werden lokal protokolliert. PII-Redaktion vor Speicherung.
  • Evaluationssuiten lokal; keine latent trainierten Telemetriedumps in externe Dienste.
  • Modelllebenszyklus:
  • Modell-Registry on-prem, Versionierung, Reproduzierbarkeit. Quantisierung und Kompilierung sind deterministische Build-Schritte.
  • Unterschiedliche Hardwarepfade (CPU, GPU, Embedded) als bewusste Zielplattformen mit Benchmarks.
  • Agenten:
  • Aktionen eines Agenten sind Events mit Autorisierung. Kein „freien Lauf“ – Policies geben Funktionsaufrufe frei.
  • Sicherheitsgurt: Rate-Limits, Budgetierung, Canary-Modus vor voller Freigabe.

Harte Entscheidungen, echte Trade-offs