Digitale Souveränität ist kein Feature – sie ist ein Architekturprinzip. Nachdem wir unsere Toolchain auf Open Source umgestellt haben, stand der nächste Schritt an: Die Infrastruktur hinter den Tools strategisch neu denken.
Digitale Souveränität ist kein Feature – sie ist ein Architekturprinzip. Nachdem wir unsere Toolchain auf Open Source umgestellt haben, stand der nächste Schritt an: Die Infrastruktur hinter den Tools strategisch neu denken.
In diesem Beitrag zeigen wir, wie unsere moderne IT-Architektur aussieht – container-basiert, automatisiert, skalierbar und vollständig unter unserer Kontrolle.
Viele Unternehmen ersetzen zwar einzelne Tools, bleiben aber strukturell abhängig:
Unser Ziel war klar: Ein Fundament schaffen, das uns maximale Kontrolle, Flexibilität und Zukunftssicherheit bietet.
Wir setzen auf eine modulare Infrastruktur, die sich an DevOps-Prinzipien orientiert – aufgebaut auf offenen Standards und vollständig dokumentierbar.
| Bereich | Lösung / Technologie | Warum wir das nutzen |
|---|---|---|
| Orchestrierung & Containerisierung | Kubernetes | Standardisiert, skalierbar, Cloud-native ready |
| Hosting | Bare Metal & Kubernetes | Volle Kontrolle, kein Vendor Lock-in |
| Configuration Management | Ansible | Automatisierte Provisionierung und Updates |
| CI/CD | GitLab CI | GitOps-kompatibel, selbst gehostet |
| Monitoring & Logging | VictoriaMetrics, Grafana, VictoriaLogs | Hohe Performance, Metrik-getriebenes Alerting |
| Storage & Backup | Velero, Restic, MinIO | Kubernetes-native, S3-kompatibel, automatisiert |
| Secrets Management | Vault, Infisical | API-gesteuert, Zero Trust ready |
| Authentifizierung | Keycloak, Authentic | Zentrale Identität, OpenID Connect, Multi-Faktor möglich |
Alle Änderungen an der Infrastruktur werden versioniert – kein manuelles Herumklicken, keine Intransparenz. Das bringt:
Nicht alles muss sofort automatisch live gehen. Wir setzen auf staged pipelines mit manuellen Gates für sicherheitskritische Deployments.
Und vor allem: Wir haben wieder den Überblick – und die Kontrolle.
Natürlich war nicht alles reibungslos. Ein paar Learnings aus dem Umbau:
| Herausforderung | Lösung |
|---|---|
| Ressourcenverbrauch von Kubernetes | Feintuning von Nodes und Workloads |
| Komplexität im Monitoring | Standardisierte Dashboards & Alert-Regeln |
| Storage-Redundanz | MinIO + automatisiertes Backup mit Velero |
| Interne Skill-Gaps | Schulung & Pairing in DevOps-Teams |
In Teil 4 unserer Blogserie zeigen wir:
Unsere Infrastruktur ist kein Geheimnis – sondern eine Einladung zum Dialog. Wer ähnliche Wege geht oder starten will: Lasst uns reden.
Welche Architekturentscheidungen habt ihr getroffen?
Was funktioniert bei euch – und was nicht?
Wir freuen uns auf den Austausch.
In unserer Discord Community findest du Antworten auf deine Fragen rund um das Thema ayedo, Kubernetes und Open Source. Hier erfährst du in Realtime was es Neues bei ayedo und unseren Partnern gibt und hast die Möglichkeit mit unserem Team in direkten Kontakt zu treten.
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →