A consortium of five Dutch organizations has started ECOFED, an ambitious cloud project funded by the Dutch government and the EU. The goal is to develop a federated European cloud as an alternative to American hyperscalers.
ECOFED, which stands for European Cloud services in an Open Federated ecosystem, is an initiative of Info Support, i3D.net, BIT, AMS-IX and TNO. The project is part of the broader IPCEI-CIS program (Important Project of Common European Interest on Cloud Infrastructure and Services), for which the EU is providing €2.6 billion.
We recently attended a knowledge sharing session on ECOFED at Info Support’s office to learn a little more about it. In addition to the plenary sessions there, we spoke briefly with Lammert Vinke, Unit Manager at Info Support and responsible for ECOFED, among other things, and Erik Langius, ECOFED program manager at TNO.
Why ECOFED is important
The main goal of ECOFED is to increase European digital sovereignty. By developing open interfaces and open-source software tools, the project aims to reduce dependence on U.S. cloud providers.
Bas Meerman, CTO of Info Support, explains during a presentation what ECOFED is ultimately about. “We want to move from an ego system to an ecosystem, with open source technology, open standards and an open playing field.” This should lead to more choice for users and better portability of cloud data and services. The latter is ultimately what it’s all about. Today’s “ego system” makes it very difficult, if not impossible, to move completely freely between different (cloud) environments.
A third advantage that ECOFED is supposed to offer organizations, besides portability and easy switching between Cloud Service Providers (CSPs), is scalability. This, of course, has always been an argument of hyperscalers as well, but really only applies there within their own environment. With ECOFED, however, it should also become a lot easier to scale across environments.
ECOFED is a federated layer
A core aspect of ECOFED is the decoupling of different cloud layers. You can actually include all aaS acronyms under this: IaaS, PaaS, NaaS, SaaS. In the words of Vinke, “the fundamental concept of ECOFED is that the application is separate from the infrastructure.” To make applications suitable for multiple types of infrastructure, it is necessary to have a layer between the application and the infrastructure. In fact, that is what ECOFED is, or actually should be, since the founding members only started it about a year ago. It is also important to further emphasize that the components of ECOFED are open source.
At the end of the day, ECOFED is intended to ensure that the customers of IT vendors and cloud service providers have a bigger say in things. In order to achieve this, part of the ECOFED project is to join EU marketplace developments for cloud services, such as DOME, where customers can find applications that can meet their requirements. A Dutch marketplace can be developed in addition to a general ECOFED marketplace and linked to the EU marketplaces.
What do users gain from ECOFED?
Langius outlines the benefits of such marketplaces for end users: “Users can search in such a marketplace based on the requirements they have: the greenest application, availability in different zones, but you can also ask for workloads to be moved to locations where power prices are lowest.” He goes on to name another benefit in terms of application availability. According to him, organizations “get a failover on the software layer, so to speak,” if they use the federated layer.
By the way, when we talk about end users at ECOFED, we are talking about buyers of cloud services in a B2B context, not end customers. End users do not notice this federated layer if all goes well. They don’t “see” it anywhere, but configure the requirements they have in the application. Of course, those applications have to be made suitable for it. That requires a little customization. The developers of the application have to do this. The ECOFED environment and its developers obviously have no control over that.
The ECOFED federation layer consists of different components. Of course, there is a control plane. This must be able to deal with restrictions around the locations where certain data may be placed. In addition, there is a component that determines the best place for each workload.
What does ECOFED mean for Cloud Service Providers?
Of course, a successful deployment of a federated European cloud needs more than software vendors and end customers. Cloud Service Providers (CSPs) also play an important role here. After all, they must deploy their own implementation of an application in their environment. “If a customer starts looking for an application, the federation layer can determine which implementation is the best,” Meerman points out.
To show that what ECOFED wants is more than just a good idea, we get to see a demo of how a VM is moved between the environments of BIT, Info Support and TNO. These are environments built on different technologies. BIT uses OpenNebula, Info Support’s environment runs on KVM combined with Libvirt and TNO’s on OpenStack. In the demo, transferring the VM is seamless, despite the totally different environments. This would not have been possible without the federated layer.
Portability works both ways
Things like portability and the ability to quickly switch between service providers sound good from a customer’s perspective. We certainly see that as a big advantage as well. Those customers are not stuck in a specific environment.
But what about the CSP? Surely it has a less stable customer base now, because they can easily choose to go elsewhere. Vinke says that thanks to ECOFED, the CSP itself will also have more portability. Here, he references recent developments at Broadcom and VMware. “Switching from Broadcom to another vendor is much easier for CSPs through ECOFED,” he indicates. “So the pressure model of private equity no longer works,” he concludes.
Furthermore, Vinke also sees benefits in terms of digital infrastructure stability. “The bug in Crowdstrike would have had less impact if the application, through federated principles, had run on a more technologically diverse landscape,” according to him. “The impact of technical failure in a specific technology is then smaller, and switching to a different infrastructure can then be done much faster.”
On this point, Langius notes that integrating with ECOFED gives CSPs more flexibility. They can be more responsive to what customers want. “If you integrate with the federated layer, you can offer a different offering to your customers than if you don’t,” he states. Assuming that this offering is one that customers actually want, ECOFED should therefore actually provide more business opportunities for CSPs. It may also cause CSPs to continue to look even more actively at what is happening in the market and what is of interest to customers. In principle, that should also be able to keep the quality of services provided higher.
Up next: continuous development, beyond technology as well
ECOFED did not happen overnight, that much is clear. Nor is it an easy job. After all, the basic challenge is to make services fully interoperable. That takes quite a bit of work. Moving a VM seamlessly between three completely different environments is a nice first demo, but that’s far from enough. For starters, there needs to be something similar for containers.
According to Meerman, people are already hard at work on this and have already managed to move standalone containers as well as Kubernetes clusters. Meanwhile, work is underway to move databases. That is also important for many applications and the containers and VMs that go with them.
Ultimately, ECOFED is not just about technical issues. For example, it also seeks to address broader aspects of cloud federation, such as bidding, contracting and governance. There should also be collaborations with more services and vendors around Storage-as-a-Service and networking, Meerman gives as examples. And CSPs will also need to start working together to jointly offer new services in Europe.
When will the federated European cloud be available?
Vinke already sees quite a few hopeful signs when it comes to ECOFED. “I am confident enough to put the concepts we are currently working on into production within the next six months,” he indicates. That’s important, because that’s how you get people excited and show that parts are already available. For CSPs, he says, it is important to create reference architectures and implementations to make their stacks suitable. Langius adds that they should also provide application builders with tools to enable integration with the federation layer API.
For us, the main challenge for this project lies in convincing enough parties of it and scale ECOFED up. Technically, it already looks pretty good, from what we’ve seen. Of course, we still have to see what challenges will be encountered as it matures, but the first signs are hopeful. A project such as ECOFED is probably never truly finished, and no definite statements are made about when it will be completely ready for use in production, but we are counting on several years anyway. 2027 came up regularly during the sessions we attended.
It will certainly be interesting in the coming years to follow how much traction ECOFED gets, also because in theory the European Data Act should help get it off the ground. At least on paper, the emergence of a good and innovative European alternative to the established hyperscalers would definitely be good. However, those have their eyes on the prize too and are opening up their environments bit by bit. It won’t be as open as ECOFED is or will be anytime soon. Nevertheless, the longer ECOFED takes to fully materialize, the further the hyperscalers will close the gap. It is therefore important for the ECOFED project to keep momentum.