Der verlässliche Betrieb
für Ihren Software-Stack
Zertifiziertes Hosting cloud-nativer Software: Die ayedo Software Delivery Platform (SDP) macht Betrieb planbar – Platform Cluster für Platform-Services, Workload Cluster für Ihre Anwendungen. ayedo übernimmt den Operations-Lifecycle in der ayedo Cloud, Dedicated oder BYOC/On-Premises.
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.
Drei Betriebsmodelle
Alle Betriebsmodelle nutzen dieselben SDP-Bausteine – sie unterscheiden sich in Isolation, Infrastruktur und Preisstufe.
ayedo Cloud
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
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
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.
Software an Enterprise-Kunden ausliefern
Wenn nicht ayedo, sondern Sie (oder Ihr Endkunde) betreiben sollen: wiederverwendbares Paket statt nur Managed BYOC. Enablement und Betrieb im Vergleich unter Software an Enterprise-Kunden ausliefern.
Enablement
Workspace-Vorlage, Primitives, Air-Gap-Bundle, Runbooks und Update-Züge – Ihr Team fährt die Sites.
Managed auf Kunden-K8s
Der Endkunde stellt Kubernetes; ayedo übernimmt Day-2 Ihrer Anwendung. Oft der schnellere Weg bei wenigen Sites.
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.
Identity
ayedo ID authentifiziert Sie an allen ayedo Cloud Services – im Dedicated-Modell erhalten Sie eine eigene Keycloak-Instanz.
Code & CI/CD
GitLab stellt Ihre Repositories und CI/CD-Pipelines auf souveräner Infrastruktur bereit.
Delivery
Argo CD liefert Ihre Anwendungen per GitOps auf die Workload Cluster aus – ayedo betreibt die Control Plane, Ihre Teams deployen deklarativ.
Container Registry
Harbor verwaltet Ihre OCI-Images – inklusive Schwachstellen-Scanning und Signierung.
Secrets
OpenBao verwaltet Ihre Secrets, PKI und Encryption-as-a-Service – zentral und auditierbar.
Observability
VictoriaMetrics, VictoriaLogs, Traces und Grafana schaffen Transparenz über die Verfügbarkeit Ihrer Systeme und helfen, Störungen frühzeitig zu erkennen.
App Hosting
Wir betreiben Katalog-Apps und individuelle Fachanwendungen für Sie – gemanagt auf Workload Clustern.
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 SDP Komponenten & Features.
Cilium
Cilium stellt eBPF-basiertes Networking, Network Policies und Observability bereit – das Cluster-Netzwerk der SDP.
Kyverno
Kyverno setzt Policy-as-Code um: Guardrails für Images, Ressourcen, Privilegien und Best Practices.
Cert-Manager
Cert-Manager stellt automatisch TLS-Zertifikate für Ingress und interne PKI-Workflows aus.
Velero
Velero sichert Ihre Cluster auf S3-kompatibles Object Storage und stellt sie im Ernstfall wieder her – die Grundlage für Disaster Recovery.
External Secrets
External Secrets synchronisiert Secrets aus OpenBao in Ihre Workload Cluster – ohne Zugangsdaten in Git.
Ingress & TLS
Der Ingress übernimmt Eingangsrouting und TLS-Terminierung für Ihre Anwendungen und die Oberflächen der Plattform.
Exzellente Performance und maximale Uptime - dafür stehen wir morgens auf. Und manchmal sogar mitten in der Nacht.
100+ Cluster
Mehr als 100 Kubernetes-Cluster betreiben wir produktiv für unsere Kunden.
300+ Datenbanken
Mehr als 300 Datenbanken betreiben, überwachen und sichern wir im produktiven Betrieb.
1 Petabyte Object-Storage
Ein Petabyte Object-Storage betreiben wir für Backups, Artefakte und Anwendungsdaten.
100 Millionen Timeseries
4 Millionen Datapoints werden pro Sekunde von unseren Monitoring-Systemen ingestiert.
38.000+ Logs
Unsere Kollektoren erfassen Logs kontinuierlich und speichern sie DSGVO-konform – über 100 Milliarden Einträge pro Monat.
5.000+ Backups
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
Mehr als 9 Millionen Endanwender nutzen täglich Software die wir bereitstellen, im Internet oder On-Premise.
99,99% Uptime
Unsere Managed Services sind im Schnitt weniger als 1 Stunde pro Jahr nicht verfügbar.
MTTD < 5 Minuten
Unser Alerting erkennt Fehler und Ausfälle in der Regel innerhalb weniger Minuten.
Die ayedo Software Delivery Platform erfüllt die Anforderungen aktueller EU-Verordnungen. Von GDPR über NIS-2 bis DORA – designed für regulierte Branchen und kritische Infrastrukturen.
GDPR-konforme Datenverarbeitung
EU-Datenhaltung (Deutschland), Customer-Managed Keys (BYOK/BYOHSM), Verschlüsselung at rest/in transit. ISO 27001-zertifiziertes Datenschutz-Management. Mehr zur GDPR.
NIS-2-konformer Betrieb
24/7 Monitoring, Incident-Response, BCP/DR-Prozesse, Supply-Chain-Transparenz (SBOM). Mehr zu NIS-2.
DORA-ready für Finanzinstitute
IKT-Risikomanagement, dokumentierte Exit-Strategien, Drittpartei-Risiko-Management, TLPT-Readiness. Mehr zu DORA.
CRA-konforme Software Supply Chain
SBOM-Generation, CVE-Scanning, signierte Container-Images, GitOps-basierte Audit-Trails. Mehr zum CRA.
Cloud Sovereignty Framework
EU-basierte Operations, offene Standards, Exit-Fähigkeit ohne Lock-in. Mehr zum Framework.
Data Act-konforme Portabilität
Offene APIs, standardisierte Formate, vollständige Exit-Runbooks. Mehr zum Data Act.
Integrierte Compliance-Roadmap
Wie ayedo GDPR, NIS-2, DORA, CRA, Data Act und ISO 27001/9001 systematisch adressiert. Zur Übersicht.
Referenz-Sizing
Richtwerte für typische Setups – die konkrete Auslegung hängt von Ihrem Workload-Profil ab.
Workload Cluster
Pro Worker sind für Standard-Fachanwendungen typischerweise 8 Cores / 32 GB RAM vorgesehen.
Platform Cluster
Ein Platform Cluster bedient bis zu 5 Workload Cluster. Für je fünf weitere Workload Cluster planen Sie +3 Worker ein.
Mindestens 4 Worker
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.
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.
Platform Cluster
