A review of the lecture by Lena Becker (RWTH Aachen) and Martin Mai (University of Bamberg) at the SCS Summit 2026 by Lisa Seifert.
At this year’s SCS Summit There was a talk that stayed with me longer than I’d expected. Not because it was particularly loud or full of big figures – but because it described a problem that is rarely discussed so openly in our community: how many organisations are currently building the same infrastructure in parallel, each on their own, each starting from scratch?
Lena Becker from the RWTH Aachen and Martin Mai from the University of Bamberg presented the project at the summit Kube3 presented. And as I listened, it dawned on me: what the two of them were describing is actually a very consistent application of concepts we talk about a lot in the SCS community – federal infrastructure, common standards, digital sovereignty. It’s just that it’s aimed at a target group that has so far had little visibility within our community: universities.
A structural problem, not an individual weakness
Kube3 stems from a structural dilemma. Kubernetes is the right tool for many use cases at universities – scalable research workloads, multi-tenancy, modern CI/CD pipelines. But running Kubernetes requires genuine expertise: networking, storage, Linux, IAM, backup, certificate management. This is manageable for a large data centre. For a smaller university with two or three people in operations and a user base that may not even reach a critical mass to justify a business case, it is not.
The result: as the talk put it, many universities are a „Kubernetes-free zone“. Not because of a lack of knowledge – but because the cost-benefit analysis doesn’t add up if they have to do it on their own.
The answer: Federalised and deliberately diverse
Kube3 is an initiative involving three federal states: in Baden-Württemberg, these are Karlsruhe Institute of Technology (KIT)), which University of Heidelberg and the University of Tübingen; in Bavaria, the Leibniz Computing Centre (LRZ) and the University of Bamberg; in North Rhine-Westphalia, the RWTH Aachen University, the University of Münster and the University of Cologne. The aim: to set up KaaS (Kubernetes-as-a-Service) systems at several university sites, which other universities and state agencies can use under a B2B model.
What caught my attention in the technical description was the deliberate decision to opt for heterogeneity. Each site operates its own virtualisation layer – OpenStack here, KubeVirt there, Cozystack elsewhere. This reflects reality: university IT centres have established infrastructures that cannot simply be standardised. The standardisation that matters lies one level higher – in the KaaS layer, which is what users see.
The aim, as it was put at the summit, is for this layer to feel the same for everyone – regardless of what is actually happening underneath. That sounds simple, but from a technical and organisational point of view, it is anything but straightforward.
Each service is allocated a dedicated Kubernetes cluster, fully isolated with its own virtual network. Monitoring, logging, support and documentation are standardised. Anyone wishing to use Kubernetes does not need to manage it themselves.
The vision that was not quite articulated
In his talk, Martin Mai described – half in jest – the project’s long-term vision: you click on a service at your own university. It starts up somewhere – perhaps in Munich, because there’s capacity there at the moment, or perhaps elsewhere. You wouldn’t even notice. Settlement between the federal states is not in money, but in computing time credits, to avoid tax complications.
That’s still a long way off. But the direction is clear, and it aligns with what many in the SCS community envisage as the ideal of a sovereign, federal cloud infrastructure – only not for commercial customers, but for universities.
For the time being, the project is focusing on specific use cases: GitLab Runners that do not require a fixed location; the open-source library system Folio, which several federal states intend to operate jointly; AI workloads; and a persistent, portable project cloud for research consortia.
The GDPR elephant in the room
One part of the talk was particularly candid – and therefore particularly valuable. Martin Mai described an absurdity that many will recognise from everyday university life: Microsoft Copilot can be used because there is a state-level framework agreement in place that has already clarified data protection issues at a higher level. Sharing data with a neighbouring university – which, in fact, poses a much lower data protection risk – often, by contrast, requires case-by-case assessments, the completion of forms and gets bogged down in questions of responsibility.
It is therefore not the actual risk that determines whether a collaboration works in practice, but whether responsibility has already been regulated at a level above the individual institution. A network such as Kube3, which is formally recognised by the participating federal states, can achieve precisely this effect: universities can cooperate with one another without every data protection officer having to reinvent the wheel.
An open question for the community
Incidentally – almost in passing – Martin Mai raised a point that has stayed with me. In day-to-day project work, we’ve already seen situations where a setup worked in Munich but not in Erlangen – not because something was broken, but simply because Kubernetes is a standard building block, not a standard itself. It’s entirely up to the user which components they use and in what configuration.
The project is therefore exploring whether, similar to the SCS flavour definitions for virtual machines, there should be standardised Kubernetes flavours – binding conformance profiles that ensure that a cluster in Munich and one in Aachen truly deliver the same results if both pass a conformance test.
Feedback on this is very much welcome. And I think this would be a task that would fit in well with the SCS community.
The full presentation by Lena Becker and Martin Mai is available at YouTube.
