The Dual-Runtime Principle:
David Hussain 5 Minuten Lesezeit

The Dual-Runtime Principle:

In highly regulated industries such as banking and insurance, modern SaaS business models rarely fail due to application logic, but rather due to restrictive hosting requirements of enterprise customers. While agile fintechs aim to scale their platforms in standardized cloud environments, conservative institutions and public entities demand on-premises operations behind the corporate firewall due to data classification and compliance reasons. For software manufacturers, this discrepancy traditionally leads to costly codebase fragmentation and significant friction losses in platform engineering.

In highly regulated industries such as banking and insurance, modern SaaS business models rarely fail due to application logic, but rather due to restrictive hosting requirements of enterprise customers. While agile fintechs aim to scale their platforms in standardized cloud environments, conservative institutions and public entities demand on-premises operations behind the corporate firewall due to data classification and Compliance reasons. For software manufacturers, this discrepancy traditionally leads to costly codebase fragmentation and significant friction losses in platform engineering.

The resolution of this tension is achieved through the Dual-Runtime Principle. By completely decoupling the underlying Kubernetes platform, deployment model, and security policies from the physical infrastructure location, an identical operational standard for cloud and on-premises targets is created. ayedo enables companies to serve demanding enterprise customers without duplicate development efforts and to leverage regulatory sovereignty as a competitive advantage.

The Problem: Fragmentation of the Operating Model

When software vendors need to provide parallel cloud and on-premises variants of their solution, operational efficiency often collapses due to infrastructural incompatibilities. Three structural hurdles burden the operation:

1. The Phenomenon of Codebase Forking

To make applications run on vendor-specific systems in the customer’s data center, Helm charts, ingress configurations, and storage definitions are manually duplicated. This code forking leads to exponentially increasing maintenance efforts, as bug fixes, features, and security patches must be synchronized across separate repositories.

2. Operational Asymmetry in Lifecycle Management

While automated CI/CD pipelines and continuous monitoring are established in the cloud, on-premises installations often devolve into manually maintained isolated solutions. The lack of centralized telemetry, inconsistent update intervals, and manual on-site interventions drive deployment costs per customer unpredictably high.

3. Failure Due to Varying Security and Network Architectures

Different data center topologies often force ad-hoc modified firewall and routing concepts. Without a unified network standard, complex tenant separations and access rules must be renegotiated and implemented individually for each customer, massively delaying certifications and audits.

The Solution: The Location-Independent Operating Model

ayedo homogenizes heterogeneous infrastructure environments through a standardized platform architecture that guarantees identical runtime conditions on bare-metal, colocation, and customer infrastructures.

1. Network Layer Abstraction via Cilium

Regardless of whether the cluster is operated in a European data center or an isolated customer DMZ, Cilium, based on eBPF, handles all networking. All security policies, L7 traffic filters, and namespace isolations are defined as declarative network policies. This ensures deterministic routing across all target environments without requiring interventions in the physical network hardware.

2. Identical Deployment Paradigm via GitOps

The deployment of the core platform and application workloads is exclusively handled via ArgoCD. The GitOps repository acts as the single source of truth: for an on-premises deployment, only the target cluster is referenced in the Git tree. Manifests, Helm values, and configuration templates remain 100% consistent, allowing version-identical rollouts and automated drift corrections to occur everywhere according to the same standard.

3. Encapsulation of Storage, Secrets, and Observability

By using open standards such as CSI drivers for local or distributed NVMe storage, HashiCorp Vault for centralized secret management, and VictoriaMetrics for metric export, the platform operates free from proprietary dependencies. On-premises nodes securely send aggregated telemetry data over encrypted tunnels or remain completely autonomous in offline mode for highly sensitive tenants.

Strategic and Economic Benefits

  • Access to New Enterprise and Public Sector Markets: The ability to deploy directly behind the customer’s firewall without architectural changes turns strict Compliance hurdles into a sales lever for framework agreements with large banks and authorities.
  • Reduction of Development and Operating Costs by Over 50%: By eliminating separate on-premises codebases, redundant engineering efforts for maintenance, patching, and version-specific troubleshooting are completely eliminated.
  • Seamless DORA and BSI-C5 Compliance: The consistency of deployment and governance enables uniform security proofs, simplifies vendor risk assessments, and meets the regulatory requirements for controlled outsourcing.
  • Complete Technological Sovereignty: Companies remain independent from specific cloud providers and protect themselves against unpredictable price adjustments, opaque licensing models, or geopolitical risks from the US CLOUD Act.

Conclusion

True technological resilience is measured by how flexibly a platform can respond to regulatory and operational conditions. Viewing cloud and on-premises as irreconcilable opposites blocks market growth and creates unnecessary operational complexity. The Dual-Runtime Principle proves that modern Cloud-Native standards and bank-compliant sovereignty harmonize perfectly—with a single codebase, predictable costs, and full control over every deployment environment.

Frequently Asked Questions (FAQ)

How are updates applied to isolated on-premises clusters without direct internet connectivity? For fully isolated environments (air-gapped), ayedo uses containerized offline bundles. Through a mirrored, private registry (such as Harbor), signed container images and versioned GitOps manifests are imported via secure handover points. The internal ArgoCD controller then handles local reconciliation without reliance on external repositories.

What are the minimum requirements for the customer’s hardware? Standardized x86_64 or ARM64 server resources (bare-metal or virtualized via VMware/KVM) with a Linux operating system and sufficient NVMe storage are required. Since the platform encapsulates all dependencies—from CNI via Cilium to secret management via Vault—no specific proprietary storage networks or vendor-specific load balancers are necessary.

How is incident management unified across hybrid locations? Telemetry data, traces, and audit logs are standardized via VictoriaMetrics and OpenTelemetry. If network-permissible, metrics can be encrypted and transmitted to a central control dashboard. In strict isolation, the observability stack remains fully local within the customer’s data center, providing standardized Prometheus-compatible interfaces for internal operations and SOC teams.

Ähnliche Artikel

Kontakt aufnehmen