A comment on the "Deutschland Stack"

I would change the approach. We keep talking about stacks, but they don’t usually help. Why?

The Germany Stack is Germany’s national technology blueprint, solution, platform (???), which aims to create sovereign, trustworthy, and interoperable digital solutions for the federal, state, and local governments by 2028. (Smells like Gaia-X in here) With a defined tech stack of European-compatible standards and technologies, the initiative aims to accelerate digitalization while strengthening the economy, government capacity, and citizen trust in equal measure.

First of all, I have to say that the open approach is a refreshing change. Perhaps this will finally allow modern and innovative technologies to be brought into play. Even if I don’t quite understand what the Federal Ministry for Digital and State Modernization wants to work on for 2-3 years. It’s not rocket science. But hey, #Neuland, right?

I would also like to say that if I come across as too sarcastic, speak badly, or criticize harshly, it is mainly because this is “just another stack” that, at first glance, defines or says absolutely nothing new and is essentially an alternative version of existing landscapes.

Structure, landscape, and more

To maintain the tech stack, it helps to open up the map and consult the stack documentation.

First, the stack is divided into certain groups and layers (those in bold/italics are not yet included in the map):

• Infrastructure

• Development, security, and operations (DevSecOps)

• Platform

• Basic service

• Applications and services

• Interface and access

• Strategy, architecture, and governance

Infrastructure

Interestingly, infrastructure is actually treated as a physical element here, including data centers, protocols, networks, etc.

This should be removed from the map. On the one hand, listing protocols is reminiscent of the subject of computer science fundamentals, and on the other hand, this is a sub-area that may only be of interest to a few.

And in my experience, those few do not need a list of these technologies.

Development, security, and operations

This layer clearly shows that the people working here have not been actively involved in IT for some time, or have never been.

First, I would separate development from operations. I would then reintroduce the topic of observability (monitoring, logging, tracing, audit logs, etc.) into the operations layer—this was already present in the CNCF Landscape—which is already very relevant for operations (!?).

The security group is a joke... Pretty much everything is missing: key management (OpenBao), policy engines such as OPA or Kyverno, OpenFGA for ReBAC, for security scans and runtime security – Falco, Trivy, Kubescape. At the very least.

Also, “commissioning,” now known as CI/CD and GitOps... I don’t understand the map here. GitHub Actions? Cool, GH Actions is great, but how does it fit in here? Argo (CD, WF, etc.), Tekton, and Travis CI are missing from the list of minimum tools. And in practical terms, it could be expanded to include other solutions in the area of fleet management.

App definition, integration, and build should be included again in the new “development” layer. The list of programming languages is, well... cute. But dapr, Helm, Artifact Hub, Buildpacks, Packer, Tilts, etc. add value to a platform.

As a platform engineer, I might even add Backstage, but honestly, that’s too complicated for the target end users.

In development, you can also include development environments, testing solutions, etc.

Platform

Actually a bit more mature than the rest of the map. But not really good either. The integration group is very confusing. Perhaps it would be better to divide it into orchestration and integration? There is a lack of relevant tools and solutions around Kubernetes. This applies to the basis for storage, for example, as well as the container runtime area and automation. The integration (or perhaps better network) layer can then be filled with modern things such as mTLS, APISIX, CoreDNS, and the like.

The absence of NeoNephos projects is disappointing here. We already have a cloud read toolset that is completely OSS and is already funded by the EU and IPCEI-CIS...

For me, the platform should also include elements such as kubevirt, Knative, and KCP—solutions for providing workloads in different forms and colors.

Basic services

On the other hand, I find the area of basic services very exciting: the focus here is on notification systems, payment, wallets, etc. I would have liked to see something on this. What are the proposals for identity management? Where does geodata come from? Which certificate providers should be used?

Applications and services

Sounds a bit like: https://european-alternatives.eu/de/alternativen-zu ?

Strategy, architecture, and governance

Unfortunately, nothing. A fundamental strategy would at least give the whole thing some direction. Are we OSS first? If so, are companies encouraged to invest in OSS? Or are there compromises, such as purchasing pseudo-sovereign solutions?

Summary of the map

It would have been easier to simply keep the CNCF map and, for example, remove all purchased software solutions and integrate another filter that distinguishes between 100% OSS and OSS with enterprise price packages.

Overall, unfortunately, many important solutions are lost.

There is a fundamental lack of innovation. Sovereignty offers more possibilities than just using the widely known open source. Where are the specifications and ideas for confidential computing? Why are there no requirements for WebAssembly? Where are the calls to action for profound technologies that rely on eBPF?

At the Handelsblatt TECH conference, Karsten Wildberger called for sovereignty and innovation. I miss that here.

Criteria and maturity levels

It will be interesting to evaluate the individual solutions that appear on the map. This may be one of the reasons why people don’t start with hundreds of OSS projects. As I said, I would first make a fundamental distinction here: How much OSS is it? Are there any licenses that are no-gos? Is there a paywall? Is there an enterprise license?

(I would like to say here that I have nothing against paid OSS enterprise solutions. Most companies are often on their own, without millions in funding to copy a CNCF landscape.

The stack offers the following criteria:

• Digital sovereignty

• Interoperability

• Future viability

• Market relevance

• Trustworthiness

• Sustainability

And an evaluation could then look something like this.

The evaluation is always carried out in 5 stages, which are defined differently.

However, some criteria and their stage definitions are more than questionable.

Under digital sovereignty, for example, there is “Stage 3 (up to 60%): In addition to Stage 2, design capability is evaluated, i.e., the possibilities for using one’s own skills and activities in the design process.” Can someone explain this to me? If I understand correctly, it’s about using one’s own employees/time/money to “design” OSS, i.e., to further develop it? -> If it’s OSS, that’s always possible. But not every change makes sense.

Also good: “Level 5 (up to 100%): In addition to Level 4, full sovereignty is assessed, i.e., the possibilities for full influence.” -> If someone can exert FULL INFLUENCE, for example, then it is not sovereign.

Sustainability is another interesting point. The following two levels only have a remote connection to sustainability. “In addition to Level 2, research investment is evaluated, i.e., the amount of investment in research and innovation or contributors.

Level 4 (up to 80%): In addition to Level 3, StartUp is evaluated, i.e., the number of existing startups.

I understand where this comes from. But the OSS landscape is rarely fed by research, nor by startups. In some cases, a large number of companies involved in an OSS product can be harmful, causing forks and variations that are no longer viable for the future.

The part about trustworthiness is understandable. But it also shows once again that someone has not understood how OSS works. Let’s take the Linux Foundation and CNCF as examples. They invest millions of dollars in improving and qualifying the security aspects of OSS solutions. Conversely, this means that Germany must create a similarly uncomplicated offering. Otherwise, this combination of wishful thinking will continue to fail.

Open source is all well and good, but in the end, it still costs money to develop. No matter how much we hope that someone will create tools out of goodwill and interest.

OSS control

In my opinion, one thing is missing here: an OSS project should have appropriate control mechanisms, and yes, the word sounds really bad in German. So, something like a Technical Oversight Committee or a Steering Committee, for example, with clear principles, terms of office for chairpersons, etc. This can be used to control the influence of individual parties. This is probably not familiar in Berlin.

However, this is one of the most important elements for controlling the sustainability, future viability, and influence of OSS.

There is also this crazy discussion about “US/China OSS vs. EU OSS.” No, there is only OSS. How much influence each party has depends on how many companies invest in it. In fact, very few companies invest time, money, and personnel in open source. That’s where we need to start. Not by developing something else that no one uses. (Let’s take a look at the K8s contributor list https://k8s.devstats.cncf.io/d/9/companies-table, for example. How many German companies are in the top 100? Just 4-5.)

Chisel procedure and next steps

Personally, I think the open procedure is very good. However, it is unclear what further steps there will be. There is talk of workshops with the participation of associations and stakeholders. That certainly makes sense, but I would advise caution. Some, let’s call them alliances, only have their own solutions in mind, which are often not good. And many associations are simply 10 years behind. Industry associations also do not usually produce good content.

International experts, i.e., real experts, not those who sit on the Digital Council or its successor, the German Digital Strategy Advisory Council, would be the minimum requirement for guidance.

Because in the end, we are lagging behind technologically. And that is a social problem, not a technological one.

What would I change?

I would change the approach. We keep talking about stacks, but they don’t usually help. Why? They are mostly complex, there are 2-3 answers to every problem, and in reality there are not enough IT experts who can deal with them (just as there are not enough AI experts...). Stacks repeat the mistakes of the past. The problems that need to be solved are cultural, in the processes, and in people’s minds.

Therefore, my line of thinking must naturally be platforms. Cloud native platforms, internal development platforms, whatever you want to call them. The point with platforms is that I start at the top with the user and their problems, not at the bottom in the basement.

When implemented correctly, platforms as a product, not as a project, can be adapted to the situation. For AI, for edge, for distributed. Basically, it doesn’t matter what application a platform needs to be adapted for. It’s not just about providing some computing capacity, but about a solution that organizations want to use.

Find my original in German on LinkedIn: https://www.linkedin.com/pulse/ein-erster-kommentar-zum-deutschland-stack-max-k%C3%B6rb%C3%A4cher-zjbff/?trackingId=%2BtAljn3aTzGT0Q1g3q9eHA%3D%3D