We have extensive discussions about our enormous dependence on American clouds, but what exactly are we talking about? And is Europe equally dependent on all types of cloud? This article is aimed at policy makers, but it may also provide some clarity about the broader landscape to actual cloud users.

There is also a Dutch version of this page.

Cloud in Shapes and Sizes

Public cloud, private cloud, IaaS, PaaS, SaaS, IaC, CaaS – what do all these terms mean? First of all, the confusion is not your fault. These concepts do overlap, and many key players use these terms in genuinely confusing ways, sometimes intentionally.

If someone says, “we’re moving to the cloud,” that could mean anything from “we’re renting servers for our software” to “we’re firing all system administrators and running all our emails & documents through American companies from now on.”

In what follows I try to bring some practical clarity here, without attempting to create strict academic definitions, things are changing too quickly for that.

The key considerations in all of this:

How much work is taken off your hands
How much control do you still have over what happens
And how much control do you have over the future, in terms of planning and pricing

Below I use the term “servers.” For the experts, by this I always mean “virtual servers.” Also, I want to thank the many proofreaders and industry experts. This article went through three complete revisions before it worked for most people. Without you, this wouldn’t have been possible!

Here is the “ladder” of going to the cloud:

No cloud: own data center, own servers (computers). Requesting a (virtual) server can easily take weeks.
The smallest form of the cloud: “renting working servers.” Saves you the trouble of managing a data center and buying servers.
One step further: you don’t rent servers but computing power. Your software runs on someone else’s capacity. “The cloud” provides as much computing power as needed; it never “runs out.” This saves having to worry about capacity during peak loads. ("Containers as a Service")
One level higher: your software runs on someone else’s capacity, but it also uses ready-to-use managed services like databases. Saves you the need for a database administrator.
If you take this further, you end up with software that mostly runs on these managed services, including advanced ones that aren’t available everywhere in the same way (e.g., “AI language models”). Saves a lot of management effort and expertise. ("Cloud Native")
The final step: you no longer run software at all; instead, you consume “word processor as a service”—the entire program is delivered as a service. The only thing left for you to do is “functional management”; no one needs to manage/operate the system anymore. MS 365 is the prime example of this. ("Software as a Service")

At the top of this ladder, you have a lot of work but also total control. At the bottom, you have almost no technical work anymore (“everything fully taken care of”), but you are completely tied to a vendor and can never leave. The “specialized services” in 5 and 6 are different everywhere and not interchangeable.

The six options. The gear in 3 represents ‘capacity,’ while the waiters in 4 and 5 represent ‘services.’ Notice how the administrator keeps getting smaller.

Somewhere in this model, there is an optimal balance, though it varies per use case. The more critical something is to your business/government operations and the more sensitive your data, the higher up in this list you want to be. The crucial question is: “Do I own this, or is it not essential to what I do?”

Good to know, legally, it is very difficult to enforce real interoperability between providers. You can’t lawyer yourself out of this.

Computers, Capacity, Services, Specialized Services

A computer is just a computer—you can buy them anywhere. You are rarely locked into a specific vendor. It’s like buying cars: if you can drive one, you can drive them all, and you have choices.

Capacity rental is already more specific. The provider must have enough servers available to keep your software running smoothly. Capacity is not entirely interchangeable between vendors, but it is to a large extent. You can buy this computing power/capacity from multiple sources, and if needed, you can also build your own capacity in your own data center.

Services (like databases) are more complicated. Some services, like databases, are relatively standardized and available from multiple providers with minor differences.

But there are also specialized services, like AI language models, which differ from provider to provider. Once you start using these kinds of services, switching becomes very difficult. You’re locked into one of the big three: Amazon, Google, or Microsoft.

The ultimate example of a “service” is MS 365—a complete office environment offered as a service. There is only one MS 365 in the world, so you can never leave; only Microsoft provides this.

The Situation

Governments and businesses use software in all six ways described above. Many traditional tech experts see an optimal balance at the capacity level, possibly with some well-standardized services (levels 3 and 4 from the list). This prevents vendor lock-in while still offloading significant work to experts. Plus, you can always go back to your own computers if necessary.

Dutch government tech experts also believe in this approach. Logius (Ministry of the Interior) offers a “Platform” based on this model. Similarly, the Dutch association of municipalities has invested in Haven+, a standard for providing capacity.

However, many providers prefer offering level 5 and 6 solutions. These are more lucrative and create strong customer lock-in. It is very hard to ever leave. These solutions are also appealing because they provide quick results, and any potential issues are in the future.

Many modern software developers are also used to level 5, where they rely heavily on specialized services.

It’s extremely important to be precise when discussing this. Right now, a company that rents out individual servers can call itself a “cloud provider,” while cloud-native developers (level 5) have no idea what to do with such a server and wouldn’t even consider it “the cloud.” For them, everything begins (and ends) with Amazon Web Services (AWS). They work at a higher (more abstract) level and cannot work directly with computers.

Good to know: Solutions up to level 3 are widely available, including in the Netherlands and other countries. Level 4 is available “on request” in the Netherlands but is well-supported across Europe. For level 5 and 6 (like MS 365), you must go to the U.S.

Here’s More Detail

For those interested, here’s more detail on the six levels.

1: No Cloud

Classic IT, sometimes with its own data center, but in any case, computers that belong to you. Requesting a new server often took weeks or months. This also leads to policy questions, such as: why do you need that server? And we already have a database, why not use that one? Typically, your mail server would run on this, based on software that you managed and/or purchased yourself.

For many, this sounds like a blast from the past, but this type of IT is still very much alive, and modern developers can’t work with it. Requesting a server through a form and then waiting weeks? When people say we must move to the cloud, it’s because this was the old and tragic situation, which indeed no longer works.

2: Renting Servers / Automation

Essentially the same as before, you can order servers. But through the cloud, they become available almost immediately. You also no longer need to maintain your own data center, which is a lot of work and increasingly undesirable for many organizations. Running a DC involves a lot of practical concerns, such as negotiations over electricity, cooling, environmental permissions.

Servers are available for rent almost everywhere, with hundreds if not thousands of providers offering such services, including in Europe (Leaseweb, Hetzner, and many more). In fact, European providers are significantly cheaper than Amazon, Google, and Microsoft (at providing servers).

It’s important to realize that this is about renting computers, storage, or network bandwidth. Your software then runs on top of these resources.

People sometimes talk about “private cloud” when these are (more or less) private computers. For example, ensuring that a government website doesn’t share a server with online stores. However, “private cloud” is a problematic term, no one knows exactly what it means.

With money and a limited amount of expertise, it’s possible to become a provider of such services.

3: Renting Capacity / Containers / Infrastructure as Code

Instead of renting individual computers, providers (using their servers!) supply enough computing power, storage, and networking, or capacity to run your software properly.

Instead of ordering “3 servers,” you ask the provider: run this container-based software on as many servers as needed. You’re using capacity rather than a pre-agreed number of servers.

There’s also another variant called “Infrastructure as Code” (IaC). With IaC, the software you use comes with a description of the hardware/infrastructure needed to run it. This means that servers and storage are automatically provisioned. However, you still explicitly choose the number of servers, but you can easily adjust that as needed.

Both capacity and Infrastructure as Code are more or less standardized (and interchangeable). There are even more precise specifications (such as the Dutch Haven+ standard), and if your vendors support those, switching becomes even easier. This allows you to choose from multiple providers and switch between them. You can also use your own servers as a provider, enabling hybrid setups—partly on your own hardware and expanding elsewhere when needed.

The number of credible providers for these services in Europe is limited but there are options (Upcloud and Leaseweb, for example).

Becoming a capacity provider requires more than just money (though that’s also necessary). It demands a substantial amount of development effort by highly skilled professionals, who are in short supply. You can’t just buy this.

4: Cloud-Native with Limited Features

Up until this point, we were renting either servers or capacity on which we ran our own software. Servers are more or less the same everywhere, so vendor lock-in is minimal. Even the mentioned containers are fairly interchangeable.

It’s also possible to consume specific services in the cloud, such as databases, “S3 buckets,” or identity & access management (IAM).

The services your organization offers then no longer run solely on rented servers/capacity but also rely on third-party services. You are effectively stacking services.

These services can also be automatically configured and activated, which is then referred to as “cloud-native.”

This marks a huge shift from the previous “rent a server”/capacity model. If you previously had a database administrator, you don’t really need one anymore – the cloud provider handles that for you. This can be a giant leap forward in development speed, but it also comes with (significant) costs.

As long as limited use is made of these features, it is theoretically still possible to migrate away, though difficult. The cloud services used are often not, or only minimally, standardized. Services from different providers work differently. The plugs don’t fit, you can’t switch without effort.

A concrete example: Microsoft acquired GitHub in 2018 (where a lot of code is hosted). GitHub was built on Amazon Web Services (AWS). Naturally, Microsoft has its own Azure cloud, but even in 2025, GitHub still heavily relies on AWS for simple services like S3. Apparently, migrating away is very difficult!

This kind of limited cloud-native service is somewhat available in Europe (Upcloud and perhaps the much-discussed but still unknown Lidl Cloud (StackIt)). Cloud-native software developers see these as the bare minimum for getting anything done.

It doesn’t require a lot of innovation to offer these basic services, but it does require a significant investment to do it well and at scale. Additionally, you can’t just “buy” this, you need a lot of software development by smart and scarce professionals. Money alone is not innovation.

5: “Fully in the Embrace of the Cloud”

Beyond the limited services mentioned earlier, there are also highly advanced ones. The “Big Three” American cloud providers all offer globally available databases that remain internally consistent despite worldwide updates, which is very impressive.

Other services include AI solutions, queuing systems, video streaming, search engines, and much more.

Developing and offering these capabilities is incredibly complex, and no European provider can match the “Big Three.” It is what it is. No one seems to be trying, though some companies like Evroc claim they want to—but I remain skeptical.

If you adopt these advanced services, you’ve essentially chosen a lifelong partner. Your service becomes deeply integrated, making migration nearly impossible. Over time, costs often spiral. Many organizations now have “FinOps” teams to control cloud expenses. It is a full time job.

The bills for these kinds of services are often spectacular—both in cost and in lack of transparency. A developer can, with a single typo, end up consuming hundreds of thousands of euros/dollars/pounds in services per month, and even then, figuring out exactly what went wrong can be a major challenge.

At the same time, if you truly need a globally consistent and fast database, these services can be a lifesaver.

Additionally, many software developers today are locked into one of the big three providers. These developers struggle to work with (virtual) servers or smaller cloud providers. They are fully plugged into one of the major providers and cannot easily switch between them.

This is part of the reason behind calls from organizations like SIDN, which argue that Europe has lost its ability to handle IT independently. What they mean is: our workforce can now only operate within the ecosystems of a few dominant providers.

6: Software-as-a-Service / MS 365

The ultimate level: you no longer run software but leave everything to someone else. This party may run the software on its own hardware, on Infrastructure as Code, or fully in the cloud. You don’t really know, and you don’t need to, it is not for you to worry about. However, even a “local” European provider might still be using AWS behind the scenes, which might not be what you want.

Typical SaaS examples include payroll processing, newsletters, and event management software. But now, even core office software like MS 365 is SaaS.

The major cloud providers have their own various SaaS services, but many more come from independent companies. Microsoft and Google offer office workspaces ‘as a service,’ whereas AWS does not really do this. Amazon itself is now attempting to become a customer of MS 365, but they don’t yet consider it secure enough, due to previous Russian and Chinese hacks of Microsoft Azure.

Getting away from SaaS is often incredibly difficult. It often requires contract renegotiations because the ability to ‘download your own data’ was not included in the agreement (!!). And once you have that data, what then? Is there another SaaS provider where you can upload that data and continue working?

There is also software like Nextcloud, where you can choose: either you consume it as a service or you run it yourself (or with assistance).

Summary

If you choose to go ‘fully into the arms of the cloud,’ you have essentially already chosen your provider: AWS, Google, Microsoft, or perhaps Oracle. You are then tied to that provider unless you are exceptionally skilled. In the long run, this often becomes expensive.

If you opt for a more limited set of relatively standard cloud-native services, you have more choices. With this limitation, switching to other providers becomes easier. For example, a database is available from many providers, and you can also run it independently if you prefer.

If you can run your services on capacity, infrastructure as code, or a (standardized) Kubernetes setup, you have even more options, and at least technical barriers do not stand in the way of switching. However, this also means you are taking on more responsibility yourself. On the plus side, scaling up when needed is easier.

On the opposite end of the spectrum, if you use MS 365 or other services as a service, you are likely committed to them for years to come. Often, such services run on one of the big three or four cloud providers in the background, though you may not necessarily be informed about it.

Closing

A rough comparison:

“No cloud”: I roast and grind my own coffee beans for use in my own coffee maker.
“Renting servers”: I have a bean-to-cup coffee machine, and I can buy beans anywhere.
“Renting capacity”: I use regular (DE, store-brand) pre-ground coffee in my simple, affordable coffee maker (many brands available).
“Limited in the cloud”: I use any brand of instant coffee (Nescafé, store-brand) and don’t need a coffee maker at all.
“Fully in the arms of the cloud”: I have a Nespresso machine that only works with Nespresso pods.
“Coffee as a service”: I go to Starbucks, where I can order a variety of coffees. I don’t own a coffee maker, I don’t need to understand how it works, and I don’t need to keep any coffee supplies at home.

The last option is expensive but effortless.

The (European) cloud ladder: from virtual server to MS 365