Das Dual-Runtime-Prinzip:

In hochregulierten Branchen wie dem Banken- und Versicherungswesen scheitern moderne SaaS-Geschäftsmodelle selten an der Anwendungslogik, sondern an restriktiven Hosting-Vorgaben der Enterprise-Kunden. Während agile Fintechs ihre Plattformen in standardisierten Cloud-Umgebungen skalieren wollen, verlangen konservative Institute und öffentliche Träger aus Gründen der Datenklassifikation und Compliance den Betrieb im eigenen Rechenzentrum hinter der Firmen-Firewall. Für Softwarehersteller führt diese Diskrepanz traditionell zu einer kostspieligen Zersplitterung der Codebasis und zu massiven Reibungsverlusten im Platform-Engineering.

Die Auflösung dieses Spannungsfelds gelingt durch das Dual-Runtime-Prinzip. Indem die zugrunde liegende Kubernetes Plattform, das Bereitstellungsmodell und die Sicherheitsrichtlinien vollständig vom physischen Infrastruktur-Standort entkoppelt werden, entsteht ein identischer Betriebsstandard für Cloud- und On-Premises-Ziele. ayedo ermöglicht es Unternehmen damit, anspruchsvolle Enterprise-Kunden ohne doppelte Entwicklungsaufwände zu bedienen und regulatorische Souveränität als Wettbewerbsvorteil zu nutzen.

Das Problem: Die Zersplitterung des Betriebsmodells

Müssen Softwareanbieter parallel Cloud- und On-Premises-Varianten ihrer Lösung bereitstellen, kollabiert die operative Effizienz häufig an infrastrukturellen Inkompatibilitäten. Drei strukturelle Hürden belasten den Betrieb:

1. Das Phänomen der Codebasis-Gabelung (Forking)

Um Applikationen auf herstellerspezifischen Systemen im Kundenrechenzentrum lauffähig zu machen, werden Helm-Charts, Ingress-Konfigurationen und Storage-Definitionen manuell dupliziert. Diese Code-Gabelung führt zu exponentiell steigendem Wartungsaufwand, da Bugfixes, Features und Sicherheits-Patches über getrennte Repositories synchronisiert werden müssen.

2. Die operative Asymmetrie im Lifecycle-Management

Während in der Cloud automatisierte CI/CD-Pipelines und kontinuierliches Monitoring etabliert sind, verkommen On-Premises-Installationen oft zu manuell gepflegten Insellösungen. Fehlende zentrale Telemetrie, uneinheitliche Update-Intervalle und manuelle Eingriffe vor Ort treiben die Bereitstellungskosten pro Kunde unkalkulierbar in die Höhe.

3. Das Scheitern an variierenden Sicherheits- und Netzwerkarchitekturen

Unterschiedliche Rechenzentrumstopologien erzwingen oft ad-hoc modifizierte Firewall- und Routing-Konzepte. Fehlt ein einheitlicher Netzwerk-Standard, müssen komplexe Mandantentrennungen und Zugriffsregeln für jeden Kunden individuell neu verhandelt und implementiert werden, was Zertifizierungen und Audits massiv verzögert.

Die Lösung: Das standortunabhängige Betriebsmodell

ayedo homogenisiert heterogene Infrastrukturumgebungen durch eine standardisierte Plattformarchitektur, die identische Laufzeitbedingungen auf Bare-Metal-, Colocation- und Kundeninfrastrukturen garantiert.

1. Die Abstraktion der Netzwerkschicht via Cilium

Unabhängig davon, ob der Cluster in einem europäischen Rechenzentrum oder in einer isolierten Kunden-DMZ betrieben wird, übernimmt Cilium auf Basis von eBPF das gesamte Networking. Sämtliche Sicherheitsrichtlinien, L7-Traffic-Filter und Namespace-Isolierungen werden als deklarative Network Policies definiert. Dadurch verhält sich das Routing über alle Zielumgebungen hinweg deterministisch, ohne dass Eingriffe in die physische Netzwerkhardware erforderlich sind.

2. Das identische Bereitstellungs-Paradigma via GitOps

Die Bereitstellung der Kernplattform und der Anwendungs-Workloads erfolgt ausnahmslos über ArgoCD. Das GitOps-Repository fungiert als alleinige Wahrheit: Für ein On-Premises-Deployment wird lediglich das Zielcluster im Git-Tree referenziert. Manifeste, Helm-Values und Konfigurations-Templates bleiben zu 100% konsistent, wodurch versionsgleiche Rollouts und automatisierte Drift-Korrekturen überall nach demselben Standard ablaufen.

3. Die Kapselung von Storage, Secrets und Observability

Durch den Einsatz offener Standards wie CSI-Treibern für lokalen oder verteilten NVMe-Speicher, HashiCorp Vault für zentrales Secret-Management und VictoriaMetrics für den Metrik-Export operiert die Plattform frei von proprietären Abhängigkeiten. On-Premises-Knoten senden aggregierte Telemetriedaten sicher über verschlüsselte Tunnel oder verbleiben für hochsensible Mandanten vollständig autark im Offline-Modus.

Strategischer und wirtschaftlicher Mehrwert

• Erschließung neuer Enterprise- und Public-Sector-Märkte: Die Fähigkeit, ohne Architekturänderungen direkt hinter der Kunden-Firewall zu deployen, verwandelt strenge Compliance -Hürden in einen vertrieblichen Hebel für Rahmenverträge mit Großbanken und Behörden.
• Reduktion der Entwicklungs- und Betriebskosten um über 50%: Durch die Eliminierung separater On-Prem-Codebasen entfallen redundante Engineering-Aufwände für Wartung, Patching und versionsspezifisches Troubleshooting vollständig.
• Lückenlose DORA- und BSI-C5-Konformität: Die Konsistenz von Bereitstellung und Governance ermöglicht einheitliche Sicherheitsnachweise, vereinfacht Vendor-Risk-Assessments und erfüllt die bankaufsichtlichen Vorgaben an kontrollierte Auslagerungen.
• Vollständige technologische Souveränität: Unternehmen bleiben unabhängig von spezifischen Cloud-Anbietern und schützen sich vor unvorhersehbaren Preisanpassungen, intransparenten Lizenzmodellen oder geopolitischen Risiken durch den US CLOUD Act.

Fazit

Wahre technologische Resilienz bemisst sich daran, wie flexibel eine Plattform auf regulatorische und betriebliche Rahmenbedingungen reagieren kann. Wer Cloud und On-Premises als unvereinbare Gegensätze begreift, blockiert sein eigenes Marktwachstum und erzeugt unnötige operative Komplexität. Das Dual-Runtime-Prinzip beweist, dass moderne Cloud-Native Standards und bankenkonforme Souveränität perfekt harmonieren – mit einer einzigen Codebasis, planbaren Kosten und voller Kontrolle über jede Bereitstellungsumgebung.

Häufig gestellte Fragen (FAQ)

Wie werden Updates auf isolierten On-Premises-Clustern ohne direkte Internetanbindung eingespielt? Für vollständig abgeschottete Umgebungen (Air-Gapped) nutzt ayedo containerisierte Offline-Bundles. Über eine gespiegelte, private Registry (wie Harbor) werden signierte Container-Images und versionierte GitOps-Manifeste über gesicherte Übergabepunkte importiert. Der interne ArgoCD-Controller übernimmt anschließend die lokale Reconciliation ohne Abhängigkeit von externen Repositories.

Welche Mindestanforderungen stellt das Betriebsmodell an die bauseitige Hardware des Kunden? Voraussetzung sind standardisierte x86_64- oder ARM64-Serverressourcen (Bare-Metal oder virtualisiert über VMware/KVM) mit Linux-Betriebssystem und ausreichend NVMe-Speicher. Da die Plattform alle Abhängigkeiten – vom CNI via Cilium bis zum Secret-Management via Vault – selbst kapselt, sind keine spezifischen proprietären Speichernetzwerke oder herstellerspezifischen Load-Balancer erforderlich.

Wie wird das Incident-Management über hybride Standorte hinweg vereinheitlicht? Telemetriedaten, Traces und Audit-Logs werden standardisiert über VictoriaMetrics und OpenTelemetry erfasst. Sofern netzwerktechnisch zulässig, können Metriken verschlüsselt an ein zentrales Leitstand-Dashboard übertragen werden. Bei strikter Isolation verbleibt der Observability-Stack vollständig lokal im Kundenrechenzentrum und stellt dort standardisierte Prometheus-kompatible Schnittstellen für die internen Betriebs- und SOC-Teams bereit.