DATEV & UhuruTec: „Wir bauen ein SCS-konformes, cloud-natives Rechenzentrum“

Auf dem Sovereign Cloud Stack Summit 2026 am 21. Mai haben Martin Seebe, leitender Berater Plattformen und Infrastruktur bei der DATEV eG, und unser Geschäftsführer Matthias. Haag zusammen unserer gemeinsames Projekt präsentiert:

Screenshot vom Vortragsvideo: Titel ‘Wir bauen ein SCS konformes Cloud-natives Rechenzentrum’ mit Martin und Matthias.”

Wir freuen uns über die gute Kollaboration mit der DATEV!
Hier eine Zusammenfassung des Vortrags:

Wie kam’s zur Zusammenarbeit?

Wenn eine recht junge Firma wie die UhuruTec AG schon in ihrem Gründungsjahr mit einem so großen Kunden arbeitet, darf man neugierig sein, wie das geklappt hat.

2022, im Gründungsjahr der UhuruTec AG, hielt Matthias zusammen mit unserem Vorstand Jan Klippel einen Vortrag auf der CloudLand Konferenz: Dein Datacenter, aber als Cloud! – Bare Metal Server provisionieren.

Ein Kollege von Martin, der Werner, war im Publikum gesessen und hat gesagt er “will das haben was die bauen, und zwar genau so wiedie das bauen” 🙂 (1:15)

Danke, Werner!

Nach einem ersten Kennenlernen folgte ein Proof of Concept und am SCS Summit 2023 auch ein persönliches Treffen von Martin und Matthias. Alles sah sehr vielversprechend aus für die damals noch sehr junge UhuruTec AG, und dann kam raus – die DATEV hat sich für Canonical entschieden. 🙁

Dachte ich: OK, Buch zuklappen, schade. Schön wär’s gewesen! – Matthias Haag (1:50)

Aber die DATEV ist nicht glücklich geworden mit Canonical, und beim nächsten SCS Summit ein Jahr später haben sich Martin und Matthias wieder getroffen und erneut ausgetauscht.

Und jetzt stehen wir hier und erzählen ein bisschen! – Matthias Haag (0:49)

Warum? Was ist der Treiber?

Um zu verstehen, warum die DATEV eG die UhuruTec AG ausgewählt hat statt Canonical, muss man verstehen, wer die DATEV ist und was ihre
Ziele sind.

Kurzvorstellung: Ein paar Zahlen zur DATEV (2:40)

Die DATEV ist eine Genossenschaft für Steuerberater, Rechtsanwälte und Wirtschaftsprüfer, und eines der größten Softwarehäuser Europas. Mehr als 9.000 Angestellte arbeiten für 40.000 Mitglieder. 9.000 ist auch die Zahl des monatlichen (!) Zuwachses an Nutzern.

Und deshalb brauchen wir eine stabile, funktionierende Plattform.
Martin Seebe (4:45)

Dieses Wachstum ist der Haupt-Treiber hinter der Migration in die private Cloud. Bisher hat die DATEV in erster Linie vertikal skaliert (“Scale Up”, wie ein Hochhaus): Große Anwendungen liefen (und laufen) auf Großrechnern (Mainframes). Das geht nicht beliebig lange, denn irgendwann sind auch die größten Großrechner nicht mehr groß genug, und 2023 war der DATEV klar:

Die Show muss irgendwie weiter gehen, und damit das klappt, müssen wir in die Breite skalieren.
Martin Seebe (5:18)

Aber Skalierung und Performance war nicht der einzige Grund. Auch wollte die DATEV weiterhin agil sein und ihren Entwicklern eine gut Umgebung zur Anwendungsentwicklung bieten:

Wir haben über zweieinhalbtausend Entwickler – für die muss die Developer Experience gut sein. Es muss einfach sein, Softwareauszurollen. Das ist ein wesentlicher Aspekt.
Martin Seebe (5:36)

Außerdem war der DATEV (echte) Souveränität wichtig:

Also nicht nur was kaufen und hinstellen und irgendwie wird schon funktionieren, sondern wir wollen es verstehen, wir wollen es maintainenkönnen, wir wollen es auch betreiben können.
Martin Seebe (19:47)

Zusammenfassend: Die Probleme der DATEV RZ-Plattform Stand 2024: (6:09)

• Kosteneffizienz
• Abhängigkeit
• Security
• Skalierbarkeit
• Interoperabilität

Die Lösungsansätze

Kucken wir mal, was es auf dem Markt gibt. Wir wollen einen Standard. Standard wäre für uns natürlich eine Kubernetes-basierende Plattform.
Martin Seebe (6:53)

Gar nicht so einfach!

Alternative Kubernetes Produkte – Long List (17 Kandidaten) (6:56)

Wir hatten eine Untersuchung: Wie muss diese Plattform ausschauen?
Wie wollen wir sie erweitern?
Martin Seebe (6:53)

Was waren die Anforderungen im Kern?

• Schnelle Bereitstellung
• Standardisierung
• Modularisierung
• Ausfallsicherheit (Redundanz)
• Developer Experience – einfaches Ausrollen neuer Software

Damit war klar: Diese Anforderungen deckt nur ein “Cloud native“ Ansatz ab. Kein Lift&Shift. Neu schreiben.
Martin Seebe (5:40)

Warum UhuruTec und nicht einer von den “Großen”?

Warum haben wir uns jetzt eigentlich für UhuruTec entscheiden? [Die Folie] Hat sich der Matthias gewünscht – hab ich gedacht – ja, klar!
Martin Seebe (8:20)

Ein Hund is er schon, unser Matthias 🙂

Ein Projekt in der Größenordnung ist natürlich etwas besonderes für die damals noch sehr junge UhuruTec AG.

Gegenüberstellung Canoncial und UhuruTec. (8:20)

Warum ist da ein Stoppschild bei Support und Wartung? Natürlich haben wir PoCs gemacht und die Software angeguckt, die Plattform angeguckt und festgestellt, na ja, kann man nicht beantworten wenn Regelbetrieb ist, wissen wir einfach nicht.

Was heraussticht aus meiner Sicht, das war das Thema:
Automatisierung. Wir hatten eben mit Canonical im PoC, die haben dann so “behind the curtain” irgendwas gebaut für uns und haben dann immer so’n Teams Call gemacht: “Ey, könnt ihr mal kucken, wie schaut es aus? Funktioniert es für euch?” Dann haben wir Fragen gestellt. “Ja, mach mer
nächste Woche.” Sag immer da, was ist da los, ne? Was passiert in der Woche? Die haben da irgendwas gebaut, und gesagt: “Ja, jetzt kann man das machen.” Das war für mich nicht nachvollziehbar.

Und das war mit der Lösung von UhuruTec ganz anders. Das skaliert, das ist automatisiert. Es war klar, das ist eine modulare Architektur, wo wir auch Einblick und Verständnis hatten.
Martin Seebe (8:23)

Die UhuruTec AG punktete insbesondere bei:

• Kosten und Effizienz.
• Automatisierung.
  • “Die Lösung von UhuruTec ist automatisiert und modular.” (9:29)
  • “Über drei Monate hinweg haben wir die Plattform fast täglich neu
    hochgezogen. […] Kein Thema.” (9:52)
• Support und Wartung.
  • “Für uns nicht nachzuvollziehen, was bei Canonical zwischen zwei
    Teams Calls passiert.” (9:05)
• Innovationspotential.
  • “Wie ist die [Lösung] gebaut? Wie ist die technologisch gebaut?” (10:15)
  • “Wir wollten nicht mit Ansible hantieren.” (10:22)

Die Lösung im Schnelldurchlauf

Was haben wir denn da hin gebaut?(10:30)

• Drei Availibility Zones im Raum Nürnberg
• Sechs Umgebungen
• GitOps
• SCS-konform

Der Storage ist alles Ceph – von der CLYSO.
Matthias Haag (13:37)

Von unten angefangen

Die Architektur kombiniert Bare-Metal-Provisionierung mit Kubernetes-nativer Orchestrierung und setzt dabei auf eine vollautomatisierte, GitOps-basierte Pipeline. Im Zentrum steht Metal³ mit Ironic als Backend, das über das BMC-Interface Server bootet. Ein individuell generiertes ISO-Image startet den Ironic Python Agent, der Hardware-Inventur durchführt und den Server für die Betriebssystem-Installation vorbereitet. Das OS-Image wird dynamisch.bereitgestellt, und der erste Kubernetes Control Plane Node startet, gefolgt von paralleler Skalierung.

“Und wenn man erst mal Kubernetes hat, wird alles ganz einfach.”
Matthias Haag (15:40)

Für Storage kommt Ceph von CLYSO zum Einsatz, ein Partner von UhuruTec. OpenStack wird als Helm-Chart in den Kubernetes-Cluster integriert, ebenfalls über GitOps-Operatoren. Dies ermöglicht eine deklarative Konfiguration aller Komponenten in einem zentralen Repository.

Das Monitoring vermeidet Workload-Overhead. Metriken werden auf den Nodes via Prometheus Node Exporter und Zabbix gesammelt, aggregiert und an ein dediziertes Management-Cluster übertragen. Für Langzeitdaten kommt Mimir zum Einsatz. Die UI-Layer sind Grafana und Zabbix.

Für das Logging nutzen wir Fluent Bit auf den Nodes, das Logs in einen Kafka-Cluster streamt. Dieser dient als Backpressure-Puffer, falls die Verbindung zum Management-Cluster unterbricht. Fluent Bit parst die Logs in strukturierte Formate und leitet sie an OpenSearch weiter.

Die Netzwerkinfrastruktur nutzt aktuell eine Multicast-Domain, migriert aber schrittweise zu einer gerouteten Fabric mit BGP. Die Umgebung ist isoliert und in Enklaven unterteilt.

Aktuell umfasst die Plattform etwa 380 Nodes mit dem Ziel von 1.000 bis 2028. Traditionelle IBM-Großrechner werden durch horizontale Skalierung auf der neuen Plattform ersetzt.

Die Hybrid-Architektur kombiniert On-Premises-Betrieb mit Public-Cloud-Ressourcen. Ein Multi-Vendor-Ansatz ermöglicht Flexibilität. Betrieblich bleibt die Hoheit bei den internen Teams. UhuruTec übernimmt nur Enablement und Problemlösung. (20:14)

Noch kurz zum Betriebsmodell: Wir als UhuruTec haben keinen Zugriffauf die produktiven Plattformen dort. Das machen alles die Kollegen [vonder DATEV]. Wir helfen, enablen, und wenn es Probleme gibt schauen wir,dass man das schnell löst.
Matthias Haag (20:40)

Fragen aus dem Publikum

• Wie wird entschieden, was in der Public und was in der Private Cloud
  deployed wird, und wie werden beide gegeneinander abgesichert? (21:12)
  • Die Plattform unterstützt sowohl On-Premises als auch Public Cloud.
    Dinge, die in der Public Cloud verfügbar sind, aber in der Private Cloud
    nicht, können so genutzt werden. Es gibt mehr alternative Lieferanten.
    Zudem werden Public-Cloud-Ressourcen für Datentransfer, große
    Datenvolumina oder Backup-Themen genutzt.
• Eine Frage zur Cisco-Integration (22:13)
  • Für die Cisco-Integration kommt Cisco Intersight Connect zum
    Einsatz, das an eine Arista Fabric angebunden ist. Die Umgebung ist
    isoliert und unterteilt. Anfangs eine einfache Multicast-Domain, um
    nicht zu viel auf ein mal zu verändern, wird die Plattform jetzt
    schrittweise auf eine geroutete Fabric mit BGP umgezogen.
• Eine Frage zur Größe der Umgebung (23:21)
  • Aktuell gibt es etwa 380 Nodes, das Ziel sind 1.000 Nodes bis 2028.
    Die Plattform ist skalierbar und ermöglicht horizontale Skalierung.