Der verlässliche Betrieb
für Ihren Software-Stack
Führende Unternehmen vertrauen auf unsere Technologie ↘
Was ist die Software Delivery Platform?
Sie entwickeln, wir betreiben. Die SDP bündelt Managed Kubernetes, Identity, CI/CD, GitOps, Registry, Secrets und Observability auf Platform- und Workload-Clustern. Die darunterliegende ayedo Cloud (Compute Cloud, Edge Cloud, Shared Services) stellt Infrastruktur und Multi-Tenant-Dienste bereit – dokumentiert auf docs.ayedo.de .
Platform Cluster
Infrastruktur · ayedo Cloud
Substrat unter jedem Workspace · Compute Cloud · Edge Cloud · Dedicated · BYOC / On-Premises — getrennt von den SDP-Blocks oben
Platform · SDP (Polycrate)
Workload-Workspace
Blocks (Apps)
Workload Cluster
Auf Managed Kubernetes
laufen Ihre Fachanwendungen
und Managed Apps
. ayedo übernimmt den Cluster-Betrieb; die Workload Cluster nutzen die zentralen Platform-Services Ihres Betriebsmodells.
Workloads
Apps
Drei Betriebsmodelle
Alle Betriebsmodelle nutzen dieselben SDP-Bausteine – sie unterscheiden sich in Isolation, Infrastruktur und Preisstufe.
ayedo Cloud
Multi-Tenant · ayedo-Accounts
- ✓ Sie nutzen zentrale Shared-Instanzen von ayedo ID, GitLab, Argo CD, Harbor, OpenBao, Grafana und weiteren Services.
- ✓ Ihre Umgebung wird über Tenants sauber isoliert.
- ✓ Managed Kubernetes steht in vielen Regionen bei verschiedenen Providern zur Verfügung – die Compute-Ressourcen laufen auf ayedo-Accounts.
- ✓ Sie starten schnell und mit minimalem Betriebsaufwand.
Dedicated
Single-Tenant · ayedo-betrieben
- ✓ Sie erhalten ein eigenes Platform Cluster, exklusiv für Ihr Unternehmen.
- ✓ Alle SDP-Apps laufen als dedizierte Instanzen.
- ✓ Sie profitieren von höherer Isolation und individuellen SLAs.
- ✓ Das Modell eignet sich besonders für regulierte Umgebungen.
BYOC / On-Premises
Ihre Infrastruktur
- ✓ BYOC: Sie stellen Ihren eigenen Cloud-Account oder Infrastruktur-Provider bereit.
- ✓ On-Premises: dasselbe Modell läuft in Ihrem eigenen Rechenzentrum.
- ✓ Air-Gap-Umgebungen und Enterprise-Anforderungen sind möglich.
- ✓ Bitte beachten Sie die technischen Voraussetzungen – siehe FAQ weiter unten.
SDP-Bausteine
Jeder Baustein verfügt über eine eigene Detailseite. Die SDP ist das Produkt – angeboten als ayedo Cloud, Dedicated oder BYOC/On-Premises. ayedo ID authentifiziert Ihre Nutzer an den ayedo Cloud Services.
Managed Kubernetes
Ihre Cluster laufen in der ayedo Cloud, Dedicated oder BYOC/On-Premises – Control Plane und Betrieb übernimmt ayedo.
Cluster
Compute
Identity
ayedo ID authentifiziert Sie an allen ayedo Cloud Services – im Dedicated-Modell erhalten Sie eine eigene Keycloak-Instanz.
Keycloak
ayedo ID
Code & CI/CD
GitLab stellt Ihre Repositories und CI/CD-Pipelines auf souveräner Infrastruktur bereit.
GitLab
CI/CD
Delivery
Argo CD liefert Ihre Anwendungen per GitOps auf die Workload Cluster aus – ayedo betreibt die Control Plane, Ihre Teams deployen deklarativ.
Argo CD
GitOps
Container Registry
Harbor verwaltet Ihre OCI-Images – inklusive Schwachstellen-Scanning und Signierung.
Harbor
OCI
Secrets
OpenBao verwaltet Ihre Secrets, PKI und Encryption-as-a-Service – zentral und auditierbar.
OpenBao
ESO
Observability
VictoriaMetrics, VictoriaLogs, Traces und Grafana schaffen Transparenz über die Verfügbarkeit Ihrer Systeme und helfen, Störungen frühzeitig zu erkennen.
Metrics
Logs
Traces
App Hosting
Wir betreiben Katalog-Apps und individuelle Fachanwendungen für Sie – gemanagt auf Workload Clustern.
Apps
Fachanwendungen
Cluster-Fundament
Diese Basis-Services laufen in jedem Cluster. Sie stehen selten im Vordergrund, sind für den sicheren Betrieb aber unverzichtbar. Details finden Sie in den Kubernetes Features .
Cilium
Cilium stellt eBPF-basiertes Networking, Network Policies und Observability bereit – das Cluster-Netzwerk der SDP.
CNI
eBPF
Policies
Kyverno
Kyverno setzt Policy-as-Code um: Guardrails für Images, Ressourcen, Privilegien und Best Practices.
Policy
Guardrails
Cert-Manager
Cert-Manager stellt automatisch TLS-Zertifikate für Ingress und interne PKI-Workflows aus.
TLS
PKI
Velero
Velero sichert Ihre Cluster auf S3-kompatibles Object Storage und stellt sie im Ernstfall wieder her – die Grundlage für Disaster Recovery.
Backup
DR
External Secrets
External Secrets synchronisiert Secrets aus OpenBao in Ihre Workload Cluster – ohne Zugangsdaten in Git.
ESO
OpenBao
Ingress & TLS
Der Ingress übernimmt Eingangsrouting und TLS-Terminierung für Ihre Anwendungen und die Oberflächen der Plattform.
Ingress
TLS
You build it. We run it.
Exzellente Performance und maximale Uptime - dafür stehen wir morgens auf. Und manchmal sogar mitten in der Nacht.
100+ Cluster
under Management
Mehr als 100 Kubernetes-Cluster betreiben wir produktiv für unsere Kunden.
300+ Datenbanken
under Management
Mehr als 300 Datenbanken betreiben, überwachen und sichern wir im produktiven Betrieb.
1 Petabyte Object-Storage
under Management
Ein Petabyte Object-Storage betreiben wir für Backups, Artefakte und Anwendungsdaten.
100 Millionen Timeseries
im Durchschnitt
4 Millionen Datapoints werden pro Sekunde von unseren Monitoring-Systemen ingestiert.
38.000+ Logs
pro Sekunde
Unsere Kollektoren erfassen Logs kontinuierlich und speichern sie DSGVO-konform – über 100 Milliarden Einträge pro Monat.
5.000+ Backups
pro Tag
Mehr als 5.000 Backups sichern wir jeden Tag auf verschlüsseltem Langzeit-Storage – rund 150 Terabyte Backup-Volumen pro Monat.
270 Millionen End-User
pro Monat
Mehr als 9 Millionen Endanwender nutzen täglich Software die wir bereitstellen, im Internet oder On-Premise.
99,99% Uptime
im Jahresmittel
Unsere Managed Services sind im Schnitt weniger als 1 Stunde pro Jahr nicht verfügbar.
MTTD < 5 Minuten
im Durchschnitt
Unser Alerting erkennt Fehler und Ausfälle in der Regel innerhalb weniger Minuten.
Compliance & regulatorische Anforderungen
Die ayedo Software Delivery Platform erfüllt die Anforderungen aktueller EU-Verordnungen. Von GDPR über NIS-2 bis DORA – unsere Plattform ist designed für regulierte Branchen und kritische Infrastrukturen.
GDPR-konforme Datenverarbeitung
Privacy by Design & Default.
EU-Datenhaltung (Deutschland), Customer-Managed Keys (BYOK/BYOHSM), Verschlüsselung at rest/in transit. ISO 27001-zertifiziertes Datenschutz-Management. Unterstützung bei Betroffenenrechten, DPA/AVV, Incident-Response. Mehr zur GDPR
.
NIS-2-konformer Betrieb
Resilienz für kritische Infrastrukturen.
24/7 Monitoring, Incident-Response, BCP/DR-Prozesse, Supply-Chain-Transparenz (SBOM). EU-basierte Operations, MFA/PAM, Vulnerability-Management, Patch-Prozesse. Ideal für wesentliche/wichtige Einrichtungen. Mehr zu NIS-2
.
DORA-ready für Finanzinstitute
IKT-Resilienz nach Maß.
IKT-Risikomanagement-Framework, dokumentierte Exit-Strategien, Drittpartei-Risiko-Management, TLPT-Readiness. Strukturierte Incident-Meldeketten, kontinuierliche Resilience-Tests, ISO 27001-zertifiziert. Mehr zu DORA
.
CRA-konforme Software Supply Chain
Security by Design über den gesamten Lifecycle.
SBOM-Generation, CVE-Scanning, Vulnerability-Disclosure-Prozesse, Update-Management. Signierte Container-Images, GitOps-basierte Audit-Trails, transparente Lieferkette. Mehr zu CRA
.
Cloud Sovereignty Framework
Digitale Souveränität messbar gemacht.
EU-basierte Operations, offene Standards, Exit-Fähigkeit ohne Lock-in. Designed für SEAL-4 (Full Digital Sovereignty) über alle acht Souveränitätsziele. Keine Abhängigkeiten von Nicht-EU-Kontrolle. Mehr zum Framework
.
Data Act-konforme Portabilität
Switching ohne Hürden.
Offene APIs (OpenAPI), standardisierte Formate (YAML/JSON/OCI), vollständige Exit-Runbooks, Infrastructure-as-Code-Portierung. Multi-Cloud-fähig, keine Egress-Fees, funktionale Äquivalenz. Mehr zum Data Act
.
Integrierte Compliance-Roadmap
Ganzheitlicher Ansatz.
Wie ayedo GDPR, NIS-2, DORA, CRA, Data Act, Cloud Sovereignty Framework, ISO 27001/9001 systematisch adressiert. Zertifizierungen, Prozesse, technische Maßnahmen, Audit-Bereitschaft. Zur Übersicht
.
Referenz-Sizing
Richtwerte für typische Setups – die konkrete Auslegung hängt von Ihrem Workload-Profil ab.
Workload Cluster
4–10 Worker
Pro Worker sind für Standard-Fachanwendungen typischerweise 8 Cores / 32 GB RAM vorgesehen.
4–10 Worker
8C/32GB
Platform Cluster
4 Worker × 8C / 32GB
Ein Platform Cluster bedient bis zu 5 Workload Cluster. Für je fünf weitere Workload Cluster planen Sie +3 Worker ein.
Platform-Services
Skalierung
Mindestens 4 Worker
Produktionsnähe
Drei Replicas mit PDB und Anti-Affinity benötigen bei Rolling Updates (z. B. CloudNativePG) Platz für eine vierte Replica – deshalb mindestens 4 Worker.
HA
PDB
Updates
Häufig gestellte Fragen
Wesentliche Voraussetzungen und Ausschlusskriterien für den Betrieb der SDP – besonders relevant für BYOC und On-Premises. Vertiefende Informationen finden Sie auf docs.ayedo.de .
Was ist der Unterschied zwischen ayedo Cloud, Dedicated und BYOC?
Die Software Delivery Platform (SDP) ist das Produkt. In der ayedo Cloud nutzen Sie mandantenfähige ayedo Cloud Services (inklusive ayedo ID); die Compute-Ressourcen laufen auf ayedo-Accounts in vielen Regionen. Im Dedicated-Modell erhalten Sie ein eigenes Platform Cluster mit dedizierten Platform-Services, betrieben von ayedo. Bei BYOC / On-Premises stellen Sie die Infrastruktur bereit – einen Cloud-Account oder Ihr eigenes Rechenzentrum – und ayedo betreibt die SDP darauf. BYOC und On-Premises entsprechen derselben Betriebsstufe.
Warum Platform Cluster und Workload Cluster getrennt?
Platform-Services wie Keycloak, Harbor, GitLab, Argo CD, OpenBao und Observability sind zentrale Shared Services. Ihre Fachanwendungen laufen in Workload Clustern und nutzen diese Services. So bleiben Fehlerauswirkungen (Blast Radius), Dimensionierung und Updates sauber voneinander entkoppelt.
Warum keine NFS- oder SMB-backed VMs / CSI-Storages?
NFS oder SMB als Backend für Node-Disks oder CSI-Volumes ist nicht performant und fehleranfällig. Distributed Storage wie Longhorn verschärft das Problem zusätzlich, etwa durch langsame Datenbank-Fsyncs. Für Bare Metal sind lokal angebundene Disks Pflicht; Ceph ist Longhorn vorzuziehen – mit korrektem Disk-Layout und idealerweise mindestens 10 Gbit/s Netzwerkanbindung.
Warum mindestens 4 Worker?
Viele datenführende Anwendungen laufen mit drei Replicas sowie Anti-Affinity und PodDisruptionBudgets. Rolling Updates starten häufig eine vierte Replica. Mit nur drei Workern kann das PodDisruptionBudget das Update blockieren – ein typisches Beispiel ist CloudNativePG.
Welche Netzwerk-Voraussetzungen gelten für BYOC/On-Prem?
Erforderlich sind ein stabiles Underlay, ARP-fähige Floating IPs beziehungsweise VIPs und idealerweise BGP. Hinzu kommen planbare Pod- und Service-CIDRs, eine funktionierende Kommunikation zwischen den Nodes sowie zuverlässiges DNS und NTP. Eine Freigabe von „nur Port 443“ ohne Konzept für Cluster-Traffic und Image-Pulls ist nicht tragfähig – ausgenommen echte Air-Gap-Umgebungen mit Registry-Mirror.
Brauchen wir separates Object Storage?
Ja. Velero und Backup-Pipelines benötigen S3-kompatibles Object Storage zusätzlich zu den Node-Disks. Backups auf demselben NFS- oder lokalen Storage stellen kein Disaster Recovery dar.
Warum wirkt cloud-native oft teurer als mein alter Root-Server?
Idiomatische Muster wie 15-Factor und die Isolation pro Anwendung und Datenbank erzeugen mehr Pods, Volumes und Reserven – im Gegenzug erhalten Sie Hochverfügbarkeit und klar begrenzte Fehlerauswirkungen. Provider setzen zudem häufig Mindestgrößen für Volumes an (z. B. 10 GB). Profilieren Sie Ihre Workloads daher frühzeitig; mehr dazu unter 15-Factor App
.
