At the Sovereign Cloud Stack Summit 2026 on May 21, Martin Seebe, Lead Advisor for Platforms and Infrastructure at DATEV eG, and our CEO Matthias Haag jointly presented our collaborative project:
Screenshot from the presentation video: Title ‘We’re Building an SCS-Compliant Cloud-Native Data Center’ with Martin and Matthias.”
We’re thrilled about our great collaboration with DATEV!
Here’s a summary of the presentation:
How did the collaboration come about?
When a relatively young company like UhuruTec AG works with such a major client in its very first year, it’s natural to wonder how that came about.
In 2022, during UhuruTec AG’s founding year, Matthias, together with our board member Jan Klippel, gave a presentation at the CloudLand conference: Your Data Center, but as a Cloud! – Provisioning Bare-Metal Servers.
One of Martin’s colleagues, Werner, was in the audience and said he “wants what they’re building, and exactly like the way they’re building it”
Matthias Haag (1:15)
Thanks, Werner! 🙂
After an initial meeting, a proof of concept followed, and Martin and Matthias also met in person at the SCS Summit 2023. Everything looked very promising for UhuruTec AG, which was still very young at the time, and then it came out – DATEV had chosen Canonical. 🙁
I thought: OK, close the book, too bad. It would have been nice!
Matthias Haag (1:50)
But DATEV wasn’t satisfied with Canonical, and at the next SCS Summit a year later, Martin and Matthias met again and exchanged ideas once more.
And now here we are, sharing a little bit about it!
Matthias Haag (0:49)
Why? What is the driving factor?
To understand why DATEV eG chose UhuruTec AG over Canonical, you have to understand who DATEV is and what its goals are.
Brief Introduction: A Few Facts About DATEV (2:40)
DATEV is a cooperative for tax advisors, attorneys, and certified public accountants, and one of Europe’s largest software companies. More than 9,000 employees work on behalf of 40,000 members. 9,000 is also the number of new users added each month (!).
And that’s why we need a stable, functioning platform.
Martin Seebe (4:45)
This growth is the main driver behind the migration to the private cloud. Until now, DATEV has primarily scaled vertically (“scale up,” like a skyscraper): Large applications ran (and still run) on mainframes. This can’t go on indefinitely, because eventually even the largest mainframes won’t be big enough, and by 2023, it was clear to DATEV:
The show has to go on somehow, and for that to work, we have to scale out.
Martin Seebe (5:18)
But scalability and performance weren’t the only reasons. DATEV also wanted to remain agile and provide its developers with a good environment for application development:
We have over two and a half thousand developers—the developer experience has to be good for them. It has to be easy to
roll out software. That’s a key aspect.
Martin Seebe (5:36)
In addition, DATEV considered (true) autonomy to be important:
So it’s not just a matter of buying something, setting it up, and assuming it will somehow work on its own—we want to understand it, we want to be able to maintain it, and we also want to be able to operate it.
Martin Seebe (19:47)
In summary: The issues with the DATEV RZ platform as of 2024: (6:09)
- Cost-effectiveness
- Dependence
- Security
- Scalability
- Interoperability
Possible Solutions
Let’s take a look at what’s available on the market. We want a standard. For us, the standard would naturally be a Kubernetes-based platform.
Martin Seebe (6:53)
Not so easy!
Alternative Kubernetes Products – Long List (17 Candidates) (6:56)
We conducted a study: What should this platform look like? How do we want to expand it?
Martin Seebe (6:53)
What were the core requirements?
- Rapid deployment
- Standardization
- Modularization
- Fail-safety (redundancy)
- Developer Experience – simple and easy deployment of new software
So it was clear: Only a “cloud-native” approach could meet these requirements. No lift-and-shift. Rewrite from scratch.
Martin Seebe (5:40)
Why UhuruTec and not one of the “big ones”?
Why did we actually decide on UhuruTec? [The slide] Matthias wanted this – I thought – yeah, sure!
Martin Seebe (8:20)
He sure is a character, our Matthias 🙂
A project of this magnitude is, of course, something special for UhuruTec AG, which was still very young at the time.
Comparison of Canonical and UhuruTec. (8:20)
Why is there a stop sign for support and maintenance? Of course, we ran PoCs and looked at the software and the platform, but we realized: We simply don’t know what will happen during regular operations.
What stood out to me was the topic of automation. With Canonical in the PoC, they built something “behind the curtain” for us and then always had a Teams call: “Hey, can you check how things look? Does it work for you?” Then we asked questions. “Yeah, we’ll handle it next week.” I always wondered: What’s happening there, you know? What’s going on during that week? They built something and then said: “Now you can do this.” That wasn’t transparent to me.
With UhuruTec’s solution, it was completely different. It scales, it’s automated. It was clear: This is a modular architecture where we also had insight and understanding.
Martin Seebe (8:23)
UhuruTec AG scored particularly well in the following areas:
- Cost and efficiency.
- Automation.
- Support and maintenance.
- “For us, it wasn’t transparent what happened between two Teams calls
with Canonical.” (9:05)
- “For us, it wasn’t transparent what happened between two Teams calls
- Innovation potential.
- “How is the solution built? How is it built technologically?” (10:15)
- “We didn’t want to tinker with Ansible.” (10:22)
The Solution at a Glance
So, what did we build there? (10:30)
- Three Availability Zones in the Nuremberg area
- Six environments
- GitOps
- SCS-compliant
Starting from the Bottom
The architecture combines bare-metal provisioning with Kubernetes-native orchestration, relying on a fully automated, GitOps-based pipeline. At the core is Metal³ with Ironic as the backend, which boots servers via the BMC interface. A custom-generated ISO image launches the Ironic Python agent, which performs a hardware inventory and prepares the server for the operating system installation. The OS image is dynamically provisioned, and the first Kubernetes control plane node starts up, followed by parallel scaling.
“And once you have Kubernetes, everything becomes really simple”
Matthias Haag (15:40)
For storage, Ceph from CLYSO – a partner of UhuruTec—is used. OpenStack is integrated into the Kubernetes cluster as a Helm chart, also via GitOps operators. This enables declarative configuration of all components in a central repository.
Monitoring helps avoid workload overhead. Metrics are collected on the nodes via Prometheus Node Exporter and Zabbix, aggregated, and transmitted to a dedicated management cluster. Mimir is used for long-term data. The UI layers are Grafana and Zabbix.
For logging, we use Fluent Bit on the nodes, which streams logs to a Kafka cluster. This serves as a backpressure buffer in case the connection to the management cluster is interrupted. Fluent Bit parses the logs into structured formats and forwards them to OpenSearch.
The network infrastructure currently uses a multicast domain but is gradually migrating to a routed fabric with BGP. The environment is isolated and divided into enclaves.
The platform currently comprises about 380 nodes, with a target of 1,000 by 2028. Traditional IBM mainframes are being replaced through horizontal scaling on the new platform.
The hybrid architecture combines on-premises operations with public cloud resources. A multi-vendor approach enables flexibility. Operational control remains with the internal teams. UhuruTec is responsible only for enablement and troubleshooting. (20:14)
Just a quick note on the operating model: We at UhuruTec don’t have access to the production platforms there. Our colleagues [at DATEV] handle all of that. We provide support, enable the process, and if there are any issues, we make sure
they’re resolved quickly.
Matthias Haag (20:40)
Questions from the audience
- How is it decided what is deployed in the public vs. private cloud,
and how are they secured against each other? (21:12)- The platform supports both on-premises and public cloud. Resources
available in the public cloud but not in the private cloud can be
utilized this way. There are more alternative suppliers. Additionally,
public cloud resources are used for data transfer, large data volumes,
or backup purposes.
- The platform supports both on-premises and public cloud. Resources
- A question about Cisco integration (22:13)
- For Cisco integration, Cisco Intersight Connect is used, connected
to an Arista fabric. The environment is isolated and segmented.
Initially, a simple multicast domain was used to avoid too many changes
at once. The platform is now being gradually migrated to a routed fabric
with BGP.
- For Cisco integration, Cisco Intersight Connect is used, connected
- A question about the size of the environment (23:21)
- Currently, there are approximately 380 nodes, with a target of 1,000
nodes by 2028. The platform is scalable and enables horizontal
scaling.
- Currently, there are approximately 380 nodes, with a target of 1,000
