When I first started thinking about this blog, one big question kept coming up: Why? Not “why bother,” but why Europe, why Kubernetes, and most importantly, why managed Kubernetes in Europe?

There’s been a growing interest in moving data and compute back to European clouds. If you’re curious about why this shift is happening, check out this post for more on the industry’s wake-up call. Over the last couple of years, though, we’ve all gotten used to the convenience, reliability, and scale of the big American cloud providers like AWS, Azure, and GCP. The idea of going back to managing individual servers feels like a step backward for most DevOps teams. With a new wave of European cloud providers focused on sovereignty and subject to European law, maybe we can finally have our data close to home—without giving up the cloud benefits we’ve come to expect.

Kubernetes has become the universal language of cloud infrastructure. Its open ecosystem and wide adoption mean teams can focus on building, without worrying much about the underlying servers. Managed Kubernetes, in particular, strikes a great balance: less operational overhead, but still all the flexibility and familiar tooling like Terraform, kubectl, and Helm. And with open standards, there’s less risk of getting locked in.

That brings us to the heart of the matter: can European providers deliver a managed Kubernetes experience that’s not just technically sound, but actually ready for the realities of enterprise IT? It’s not enough to spin up clusters on demand. What matters is whether you can plug into your SSO, connect to managed databases, set up monitoring that works with your stack, and get support when things break. Are European platforms still just playing catch-up, or are they starting to carve out their own strengths, shaped by local laws and the real-world needs of teams in Europe?

To get a real answer, I decided to go beyond the documentation and put these platforms to the test. I built a fully automated benchmarking pipeline to see not just if they work, but how well they work, and where the differences really show up when you’re building for the real world.

We are comparing four cloud providers in this study: Azure, OVHcloud, StackIt, and Hetzner. They can be subdivided into three broad categories: the American, the European cloud service providers, and the IaaS provider.

I built a GitHub Actions pipeline that reuses the same steps for every provider, except for the infrastructure and configuration part. Each cloud has its own Terraform provider, so that job is different for each one. Azure and StackIt were the easiest: after running Terraform, all data was accessible and the clusters were ready to go. OVHcloud needed a quick script to fetch the pgAdmin credentials, since I couldn’t provide my own. Hetzner, being pure IaaS, required all the configuration after deployment.

Once the cluster is ready, the pipeline continues in the same manner for all providers, a testament to the vendor agnostic nature of the Kubernetes platform layer. It deploys a demo application, then scales the deployment up until the node autoscaler is forced to add capacity. Throughout the process, the pipeline measures key metrics like provisioning time, scaling speed, and external IP availability. When the test is done, everything is cleaned up automatically so it can all start again.

The main architecture for each test consists of a Kubernetes cluster and a separate managed PostgreSQL database. Connectivity outside the cluster is handled over the public internet, though all providers do support private networking. For this benchmark, the focus is on compute and memory: by deploying a batch of pods at once, we quickly exhaust the resources on the node, forcing the system to provision another. Networking is left to the provider as much as possible. I simply provision a LoadBalancer service as part of the deployment and let the cloud provider figure out which components are needed behind the scenes.

Note: For brevity, callbacks, metrics collection, and measurement steps are excluded from the swimlane diagram.

Hetzner is a bit of an outlier here. At the time of writing, there’s no such thing as a fully managed Kubernetes solution on Hetzner Cloud. Instead, I aimed to create an architecture in the same spirit, but sacrificed quite a bit in terms of manageability and stability. Unlike the other CSPs, on Hetzner I deployed two servers: one for the master node of the tiny k3s cluster, and one for the PostgreSQL server, using a collection of scripts and templates to configure the services. It’s definitely not as smooth as using a managed Kubernetes service. I had to install nginx, set up cluster autoscalers, link worker nodes to the cluster, and connect the cluster to Hetzner. These are steps that are completely superfluous in a managed environment.

Still, Hetzner is a popular choice for cost-conscious teams, so it deserved a spot in the lineup.

Infrastructure deployment time: How quickly you can go from zero to a running cluster. Indicates how fast infrastructure changes can be made.

External IP availability: How fast your services become accessible from the outside world. Useful for understanding exposure delays.

PostgreSQL database performance: Measures the speed and consistency of managed database operations across providers.

Scaling efficiency: How well the platform handles scaling up workloads and adding capacity under load.

Kubernetes API performance: Reflects the responsiveness of the Kubernetes control plane, impacting automation and daily operations.

Before diving in the performance metrics I want to briefly look into the hosting costs of the different providers.

Pricing models for cloud resources vary widely, and the differences are as important as the performance results. Here, I compare two typical scenarios: a small cluster with two worker nodes using the cheapest available components, and a medium cluster with 10 more powerful nodes and upgraded networking. For larger clusters, the cost structure generally scales in the same way, but keep in mind that for very large or enterprise-scale clusters, the advertised rates may no longer apply, as cloud providers often negotiate custom pricing or discounts at scale, so your actual costs could differ significantly from the public numbers.

Hetzner is by far the cheapest, but you pay with your time and expertise—there’s no managed experience.

OVHcloud is aggressively priced, especially for larger nodes, and the control plane is always free.

Azure and StackIt are more expensive, but both offer a managed experience with additional features and support.

StackIt’s control plane is the priciest, but this aligns with their business focus: as the German cloud for business, StackIt is designed for enterprise customers, not for hobbyists spinning up clusters for fun. For larger clusters, the control plane cost becomes less significant.

Ultimately, the best value depends on your needs: Hetzner is unbeatable for raw price, OVHcloud is a strong value for managed K8s, and Azure offer more features and support at a premium.

After running the automated benchmarks across Azure, StackIt, OVHcloud, and Hetzner, I ended up with 59 successful runs: 17 for Azure, 13 for Hetzner, 14 for OVHcloud, and 15 for StackIt. Each run captures how a provider performed on the key metrics. The following images illustrate the comparative results for each metric and provider:

Several things stand out here. First, Hetzner delivers very quick cluster provisioning, but with a big asterisk: this is a minimal, self-managed k3s setup, not a full-fledged managed Kubernetes service. That speed comes with extra manual work and less automation.

In terms of stability, Azure and StackIt were solid. The pipeline always worked as expected. OVHcloud, on the other hand, occasionally failed to expose the application when a public IP couldn't be provisioned. Hetzner presented a different challenge: as a casual user, resource limits are low and not immediately freed when resources are deleted. This, combined with my slightly unorthodox use case, led to several pipeline failures. However, Hetzner's faster runtimes compensated, so I still managed to complete a similar number of runs to the other providers.

When it comes to exposing applications, Azure is much quicker than its European managed counterparts, and it also leads the field in scaling up. Across these results, Azure frequently comes out on top, followed by StackIt, with OVHcloud often trailing. The most important takeaway, though, is that most results are consistent and predictable. As engineers, we can build around predictable performance, so this consistency is a real advantage.

One of the biggest challenges in cloud adoption is vendor lock-in. This is the risk that your infrastructure becomes so tied to a single provider’s ecosystem that moving or going multi-cloud turns into a major project. This is where open standards and tools like Kubernetes and Terraform shine. By using Kubernetes as your platform layer and Terraform for infrastructure as code, you gain some real portability. You can define your infrastructure and workloads in a way that is mostly provider-agnostic, making it much easier to switch clouds, run hybrid, or avoid being boxed in by a single vendor. Of course, “provider-agnostic” doesn’t mean frictionless; there are always edge cases and integration challenges to consider.

In practice, there are still many differences: for example, around managed services, networking, compliance, integrations, and identity and access management (IAM). But the core experience can be remarkably consistent. This consistency is a major win for teams that want flexibility and leverage in their cloud strategy.

Not all clouds are created equal, and in Hetzner’s case, we’re not even talking about the same kind of cloud service. Running a self-managed k3s cluster on Hetzner is a whole different ballgame compared to the polished, fully managed Kubernetes services from Azure, OVHcloud, and StackIt. Hetzner’s DIY approach is lightning fast and cost-effective, but comes with extra manual work, less stability, and more operational responsibility. Hetzner’s model suits cost-conscious, hands-on teams who enjoy tinkering and want to save money, while managed services are ideal for those prioritizing ease, support, and a hands-off experience.

This investigation is just a small technical slice of a much larger puzzle. While it’s fun (and useful!) to see how these European cloud providers stack up on raw Kubernetes performance and cost, that’s only part of the story. Enterprise readiness is about so much more: identity providers, compliance, integrations, edge compute, support, and all the other facets that make a cloud platform fit for your organization.

So how successful was I in escaping the Americans? In my quest to escape Microsoft’s yoke by moving to our new European messiahs, my employee accounts are hosted by Google, my repository and pipelines live on Microsoft’s new acquisition GitHub, and while Visual Studio Code is open source, it’s also owned by Microsoft. The laptop I’m writing this on? Windows, of course. Decoupling from these ecosystems is going to be a long road and it’s not just about technology, but about making hard choices at every level: tools, platforms, habits, and even organizational culture. The path to true digital sovereignty will be gradual, expensive, and messy. If you’re interested in exploring more European alternatives, check out european-alternatives.eu.

So, take these results for what they are: a fun peek into the world of European clouds and a snapshot of how far they’ve come in a short amount of time. The landscape is changing fast, and it’s exciting to see real alternatives emerging. If nothing else, I hope this inspires you to dig deeper, experiment, and keep an open mind about where you run your next cluster.

Kubernetes in Europe: Can European Cloud Providers Compete with the American Giants?

Bij CINQ draait november om verbinding. We leren van elkaar, delen kennis en maken tijd voor gezelligheid. Of je nu bij ons op kantoor bent, op een conferentie of een paar dagen weg met je team: deze maand is er voor iedereen wat te beleven.

We trappen de maand af met de DevOps lunch. Even geen sprintdrukte, maar een moment om ervaringen te delen over CI/CD, automatisering en hoe we samenwerken aan stabiele deployments. En natuurlijk hoort daar een lekkere lunch bij.

6 november – “Can LLMs play text adventures” – Bouke Nijhuis @ JFall 2025

Onze collega Bouke staat op JFall met een talk over Large Language Models en tekstgames. Een sessie waarin techniek en creativiteit samenkomen – precies zoals we het bij CINQ graag zien.

13 november – Bordspellenavond @ CINQ HQ

Eindelijk is 'ie ingepland: de bordspellenavond. We schuiven aan met snacks, spellen en een flinke dosis gezelligheid. Of je nu komt om te winnen of gewoon voor de sfeer, gezelligheid is gegarandeerd.

17 november – Meetup Europese cloud @ CINQ HQ

De afhankelijkheid van Amerikaanse cloudproviders zoals Azure, AWS en Google Cloud groeit al jaren. Maar wat betekent dat voor onze digitale soevereiniteit in Europa — en voor organisaties in Nederland? Tijdens onze EU Cloud Meetup delen we onze bevindingen. Meer info en aanmelden via deze link.

27 november – “Can LLMs play text adventures? – Kotlin edition” – Bouke Nijhuis @ Kotlin Dev Day 2025

Bouke’s talk krijgt een vervolg bij Kotlin Dev Day. Met een frisse blik op AI, Kotlin en hoe technologie kan verrassen.

27–29 november – NerdCation Data unit

Onze Data-unit gaat er samen even tussenuit. Een paar dagen vol kennis, ontspanning en plezier – met een kookworkshop, Robot Wars en lekker eten. 

We sluiten de maand af met hoog bezoek: Sinterklaas komt naar ons kantoor en neemt voor de kinderen van onze collega's cadeaus mee! Tijdens de Sinterklaas show zijn blije gezichtjes gegarandeerd!

Op onze event pagina vind je altijd een actueel overzicht van alle geplande events. 

Neem dan contact op en meld je aan voor een event - je bent van harte welkom!

Ontdek wat er in november bij CINQ gebeurt: van DevOps lunch tot bordspellenavond, cloud meetup en Sinterklaas op kantoor.

CINQ Events november 2025

November bij CINQ: bekijk de agenda

What if a bird could store your data? Sounds crazy, right? But imagine a storage system that is lightweight like a feather and eco friendly. That’s exactly what YouTuber Benn Jordan set out to explore and the results are mind-blowing.

Ben’s star assistant? A European starling nicknamed “The Mouth”, famous for its uncanny ability to mimic sounds with ultrasonic precision. 

Convert that image into a series of high-pitched tones using a spectrogram synthesizer.

Play those tones to the starling and see if it could learn them.

If the bird memorized and reproduced the sound, it would essentially be encoding image data into its song.

Yes! When researchers analyzed ultrasonic recordings, they found that the starling had successfully copied a simplified version of the sound pattern transmitting about 176 KB of raw data through its call. Not bad for a little bird.

Ben explains that the magic came from specialized gear:

192 kHz ultrasonic microphones to capture sounds beyond human hearing.

Time-stretching software to slow down audio without losing quality.

Spectrogram analysis to visualize the bird’s “data song.”

“If this were a proper audio-based file transfer protocol with 10:1 compression, that’s nearly 2 MB per second”.

Because it proves something wild: birds can store and share data through sound. Imagine setting up a speaker in your backyard and, in theory, uploading unlimited data into songbirds. That’s not science fiction anymore, it’s science.

“The fact that you can, in theory, turn your garden into a living data center is insane.”

– no birds are harmed during the experiment and/or the writing of this blog –

I Saved a PNG Image To A Bird

What if a bird could store your data? Sounds crazy, right? But imagine a storage system that is lightweight like a feather and eco friendly...

Ever heard about feathered storage?

De afhankelijkheid van Amerikaanse cloudproviders zoals Azure, AWS en Google Cloud groeit al jaren. Maar wat betekent dat voor onze digitale soevereiniteit in Europa — en voor organisaties in Nederland?

Onze engineers doken voor je in dit onderwerp. We onderzochten Europese alternatieven zoals OVH, Stackit en Cyso Cloud, testten hun mogelijkheden en bekeken hoe volwassen deze platforms inmiddels zijn. De conclusie: de Europese cloud is nog in ontwikkeling, maar groeit snel en biedt interessante kansen voor wie voorbereid wil zijn op de toekomst.

Tijdens onze Europese Cloud Meetup delen Noud en Bouke hun bevindingen: van praktische migratie-ervaringen tot een eerlijke vergelijking tussen Europese en Amerikaanse aanbieders.

Wil je weten hoe ver de Europese cloud écht is?

Kom op 17 november naar de Meetup bij CINQ en kom er zelf achter.
Meld je aan via deze link en verzeker jezelf van een plekje.

Natuurlijk zorgen we voor een hapje eten en een drankje en daarna nemen twee CINQ’ers je mee in de wereld van de Europese cloud. 

Noud Savenije onderzoekt in zijn talk “Kubernetes in Europe: Can European Cloud Providers Compete with the American Giants?” of spelers als OVH, Hetzner en Stackit klaar zijn om bedrijfskritische Kubernetes workloads te draaien.

Bouke Nijhuis neemt ons in  neemt ons in “Migrating my Azure Function to the European Cloud” mee in zijn praktijkervaring: hoe verloopt de overstap van Azure naar Stackit en Scaleway? Met live demo’s laat hij zien waar het soepel gaat en waar je tegenaan kunt lopen.

17:30 ontvangst
18:00 eten
18:30 start presentaties
19:30 napraten & borrel

CINQ ICT, Burgemeester Stramanweg 101, Amsterdam

Ga naar https://www.meetup.com/cinq-ict/events/311355919/ om je aan te melden.

Hoe volwassen is de Europese cloud? Tijdens de EU Cloud Meetup van CINQ ontdek je of OVH, Stackit en Scaleway kunnen concurreren met Azure, AWS en Google Cloud.

Europese Cloud Meetup: Ontdek Alternatieven voor Amerikaanse Cloudproviders | CINQ

17 november: Europese Cloud Meetup

Not too long ago, I started working on an assignment where I was responsible for setting up the security layer. I had done bits and pieces before - throw in some annotations, lock down a couple of endpoints - but this time it was different. 

JWTs, authentication flows, token validation, role-based access. The whole thing! I kind of knew what JWTs were - those long tokens you slap into a header - but I hadn’t really sat down and understood how it all worked. I knew just enough to be dangerous! Until now. 

And as someone who plays drums in a band, I started to notice something familiar about it. If there’s one thing I’ve learned from years of playing in a band, it’s this: you don’t get into the venue without the right pass. Doesn’t matter if you’re the lead guitarist or the guy carrying the snare drum -  no pass, no entry! The same principle can be applied when building web apps.

Your front-end is like the roadie showing up at the venue (a.k.a. your back-end). It wants access, it wants to get in and do its thing. But the back-end doesn’t allow everyone in. He has got to check some credentials.

And that is where JWT (pronounced as ‘jot’) comes into play.

Let’s say you’ve built a slick front-end app. It’s flashy, fast, and ready to rock. Now it needs to make some calls to your back-end - to fetch user data, update profiles, maybe even post some setlists. For the non-musicians among us, a setlist is a list of songs you, as a band, plan to play during a gig. Until someone in the audience yells a request and chaos wins.

Here’s the issue: how does the back-end know who’s knocking?

As a back-end,  you don’t want to ask for a username and password on every request that comes in - that would be like showing your passport and filling out a form every time you walk past a security guard on tour. Exhausting. What we need is a backstage pass - a one-time signed token that says: “Yeah, this guy is with the band.”.

JWT stands for JSON Web Token. It’s a compact, URL-safe string made up of three parts in the following format:

[header].[payload].[signature]

Header: says what kind of pass this is, and how it was signed.  

Payload: the actual info: who the token belongs to, what roles they have, and (very important!) when it expires.

Signature: the real magic. It’s the tourmanager/organizer's signature - proof that this pass is legit and wasn’t faked in the parking lot.

Please don’t worry too much for now about the unknown words/abbreviations in the following payload example. A typical payload might look something like this:

 {
   "iss": "Creative Artist Agency",
   "sub": "user123",
   "name": "Dave Grohl",
   "role": "drummer",
   "exp": 1735689600
 }

The payload is made up of so-called claims. Claims are key-value pairs. Nothing more, nothing less. They carry the info you want to communicate. By the way, the term claim isn’t JWT trying to be fancy. In real life, a claim is when someone says something is true. When you put these in a JWT you are embedding statements (claims) about an identity - and you are expecting the receiver to trust them … if the token is valid and properly signed, that is!

From a specification point of view (RFC 7519) none of the claims you put in the JWT are required. You could even send a JWT with an empty payload, but somehow that doesn’t sound very practical. Although they are not required, certain claims are recommended and often used in practice. For example, you will always find the exp (= expiration time) claim on a JWT when dealing with authentication and/or authorization. 

Again, not required but extremely recommended. Especially exp, to prevent forever-valid tokens.

Let’s walk through the typical tour (aka JWT dance between front-end and back-end).

If we were to draw a picture of the whole thing, it would look something like this.

There are 3 actors involved in this process:

an authentication server (e.g. Google or your own developed authentication server)

Your user logs in through the front-end. The credentials go to the authentication server. The authentication server checks them, and confirms they’re legit (or not).

If all checks out then the authentication server creates and signs a brand new JWT: a signed, encoded backstage pass containing the user's ID and role. It uses a key pair to do this: a private key, kept secret like the tour manager’s official stamp, and a public key, which anyone on the team can use to verify that stamp. The private key signs the pass so it can’t be forged, and the public key helps the backend know it’s the real deal - no need to call HQ. Once signed, the token gets sent to the front-end, ready to be flashed at the next venue.

The front-end stashes it - usually in memory or localStorage, ready to rock. This token will now go on tour with every API call to the back-end.

Whenever the front-end wants to access a protected route on the back-end (like /api/setlists), it adds the token in the Authorization header of the request and this looks like this:

Authorization: Bearer eyJraWQiOiIwODI2MDdmMi05NTBkLTRkNGEtOTk0Yy1kZWFkNDY3ZDQy...   

The back-end receives the request, checks the token’s signature, confirms it hasn’t expired, and makes sure the user has the right role. But how do we check the signature? That’s where the public key part of step 2 comes into play. In order to check the JWT, the back-end needs the public key part of the key pair with which the JWT has been signed. What you usually see is that the authentication server exposes a special endpoint for retrieving the much needed public key. Only with that public key in hand can the back-end determine if the JWT has been issued by your authentication server, isn’t fake and/or hasn’t been tampered with. So, if everything checks out, you’re in.

If the security check succeeds then there is nothing left to do, other than executing the business logic and returning a response to the front-end. For as long as the JWT is valid, the front-end has access to the back-end.

Traditionally, web apps used sessions to keep track of who’s logged in. When a user logs in, the server creates a session - like writing their name on a clipboard - and stores it in memory or a database. Each time the user makes a request, the server checks that clipboard to see if they’re on the list.

Now, why then all this hassle of introducing extra components - an authentication server, tokens, signatures, the whole backstage circus with JWTs? Because you want your gig to scale! Sessions require the back-end to remember things - who’s logged in, where they’ve been, what they had for lunch. JWTs don’t. They’re stateless, meaning every server on your tour can check a pass and say, “Yep, looks good,” without phoning home to some central bouncer.

Think of it like this: instead of relying on one grumpy security guy with a clipboard at HQ, every venue on the tour has a scanner that instantly verifies your pass. They don’t need to call anyone, check a spreadsheet, or argue about your laminate - the token speaks for itself.

JWTs are awesome, but not bulletproof. Here’s where they can trip you up:

They expire - and until then, they can’t be revoked. If someone steals one, they’re in until it dies.  With this in mind you should always keep the lifespan of a JWT as short as possible. As a general rule of thumb a JWT access token should be valid for just a few minutes (certainly not hours). By the way, saying that JWTs can’t be revoked isn’t 100% true, you can in fact revoke them, but only by adding a centralized check - like a token blacklist or by means of tracking token IDs in a database. But, by doing so this would remove their stateless (and therefore scaling) benefits.

They’re readable - don’t put sensitive info in them. They're base64 encoded, not encrypted.

Storage matters - don’t put them in a place where JavaScript can easily grab them if you have XSS vulnerabilities.

As mentioned above, JWTs expire. Then what? Well, then we have to start the dance all over again. Or not? Think of your JWT as a temporary backstage pass - it gets you in, but only for a set amount of time. When it expires, you preferably don’t want to make the user log in again. You want the user experience to be as smooth as possible. That’s where the refresh tokens come in!

The refresh token is like a second pass that lives quietly behind the scenes - longer-lived, not used on every request. When the short-lived access token expires, the front-end uses the refresh token to ask for a new one. Kind of like walking up to the tour manager/organizer and saying, “Hey, can I get a new pass? Mine just ran out.” Important to remember: just like your JWT, do not lose this pass or show it off to other groupies!

your JWTs stay short-lived which reduces risk.

your users stay logged in without even noticing.

your back-end still has control. In contrast to JWTs, refresh tokens can be revoked if needed. 

Think of the refresh token as a special, long-lived backstage pass - but one that the tour manager keeps track of on a list behind the scenes. If someone causes trouble, spills beer on the mixer, or just looks shady, the manager can strike that pass off the list. From that point on, even if they flash the same pass, they’re not getting a new one. 

Some tours go even further with token rotation: every time you use the refresh token, the manager gives you a brand new one and burns the old one. It’s like swapping wristbands at every venue, so even if one gets stolen, it won’t work the next night. Unlike JWTs, which just roam free until they expire, refresh tokens give your back-end the power to kick someone off the tour at any moment.

It’s your digital backstage pass. Signed by the authentication server, handed to the front-end, and flashed at every endpoint of the back-end that asks: “Are you supposed to be here?”.

As a drummer, I’ve been let into a lot of venues with nothing more than a worn-out laminate pass on a keycord. If it’s signed, it's trusted. The same goes for your front-end app!

Leer hoe JWTs werken aan de hand van een muzikale metafoor: ontdek hoe JSON Web Tokens je webapp beveiligen met digitale backstage passen, inclusief uitleg over authenticatie, token flows en refresh tokens.

“No pass, no entry” - a musician’s take on JWTs

Onlangs kwamen onze engineers bij elkaar om een onderwerp te bespreken dat steeds urgenter wordt: soevereine cloudinfrastructuur. We spraken over Europese cloudoplossingen, de digitale onafhankelijkheid van Nederland, en onze huidige afhankelijkheid van Amerikaanse cloudproviders. In deze blog delen we de belangrijkste inzichten uit dat gesprek – én de volgende stappen die we gaan zetten.

Ons gesprek begon met een opvallende constatering: in de media gaat het vrijwel altijd over de “grote drie” Amerikaanse cloudproviders – Microsoft Azure, Amazon Web Services en Google Cloud. Zij domineren de markt, maar recente geopolitieke ontwikkelingen roepen steeds meer vragen op over de digitale soevereiniteit van Europa.

De herverkiezing van Donald Trump heeft de spanningen tussen Europa en de Verenigde Staten opnieuw aangewakkerd. Hoewel de VS een belangrijke bondgenoot blijft, groeit de zorg over onze bijna volledige afhankelijkheid van Amerikaanse cloudinfrastructuur – bij zowel overheden als bedrijven in heel Europa.

Een concreet voorbeeld van digitale afhankelijkheid

Die zorg werd heel tastbaar toen de regering-Trump actie ondernam tegen een hoofdaanklager van het Internationaal Strafhof in Den Haag en diens e-mailtoegang werd geblokkeerd.
Dat kon, omdat het Strafhof gebruikmaakt van Office 365 – een Microsoft-dienst die valt onder Amerikaanse jurisdictie en beleid.

Het incident toont een ongemakkelijke realiteit: onze digitale infrastructuur kan worden beïnvloed door buitenlandse politieke beslissingen, zelfs als Nederland daar geen directe rol in speelt.
Wanneer een bondgenoot zelfstandig essentiële digitale diensten kan uitschakelen, is dat een serieus risico voor onze digitale autonomie.

Wij zijn niet de enigen die deze afhankelijkheid zien. De website european-alternatives.eu – gelanceerd in december 2024 – zag een sterke toename in bezoekersaantallen (zie afbeelding hieronder). Dat laat zien dat de belangstelling voor Europese cloudalternatieven snel groeit.
Ook Bert Hubert, cybersecurity-expert en voormalig AIVD-toezichthouder, heeft herhaaldelijk opgeroepen tot actie om deze afhankelijkheid te verminderen.

Van politiek naar praktijk: tijd om te nerd-en

Hoewel geopolitiek de aanleiding was, zijn we uiteindelijk techneuten – dus we deden wat we het liefst doen: we gingen zelf aan de slag.

We maken momenteel vooral gebruik van Azure, met af en toe een uitstapje naar AWS of Google Cloud. Om alternatieven te kunnen vergelijken, moesten we eerst bepalen welke functies voor ons essentieel zijn.

Met onze DevOps-focus op Kubernetes werd al snel duidelijk waar het om draait. Naast container orchestration gebruiken we Azure Functions en verschillende dataservices. En ja, onze CTO heeft nog steeds die ene Java-applicatie draaien voor €0,01 per maand.

Na ons overleg kwamen we tot deze kernfuncties van een cloudplatform:

Netwerk (publieke IP’s, routing, firewalls, load balancing)

Met european-alternatives.eu als startpunt vonden we op dat moment 12 Europese providers – en het aantal groeit snel. Drie sprongen er meteen uit:

OVH Cloud – Gevestigd in Frankrijk, gesteund door de Franse overheid, en nu ook beschikbaar voor publieke organisaties.

Stackit – Een Duitse provider in handen van de Schwarz Group (het moederbedrijf van Lidl en Kaufland), vaak met een knipoog “LidlCloud” genoemd.

Cyso Cloud – Gevestigd in Nederland (voorheen Fuga Cloud), met lokale hosting en vertrouwde regelgeving.

Onze collega Noud testte de Kubernetes-mogelijkheden van OVH Cloud. De resultaten waren positief: eenvoudig op te zetten, goed gedocumenteerd en prima performance.
Met Terraform draaide hij succesvol een Kubernetes-cluster uit met de OVH-provider. De uitrol van een simpele nginx-app werkte vlekkeloos.
Een kleine kanttekening: de benaming van regio’s zou wat intuïtiever mogen zijn – dat zou migraties vergemakkelijken.

Dion ging aan de slag met Stackit, wat iets complexer bleek. Stackit was oorspronkelijk bedoeld voor intern gebruik binnen de Schwarz Group en is niet volledig publiek beschikbaar.
Na contact met Stackit-engineers op KubeCon London kregen we toegang. Het platform draait op OpenStack en biedt compute-, storage- en Kubernetes-infrastructuur. De enterprise-achtergrond is duidelijk zichtbaar. Verdere tests volgen binnenkort.

Onze CTO Bouke nam de proef op de som en probeerde zijn wekelijkse Java-applicatie van Azure Functions naar een Europees alternatief te migreren.
Dat bleek lastiger dan verwacht: Java-support ontbreekt vaak, en sommige aanbieders vereisen dat scripts binnen Kubernetes draaien – wat de kosten flink verhoogt voor simpele taken.
Dit wijst op een groeimogelijkheid: meer taalondersteuning en eenvoudigere serverless-opties in de Europese cloud.

Op basis van onze eerste verkenning hebben we drie vervolgstappen gedefinieerd:

Diepgaand technisch onderzoek – Binnen enkele maanden plannen we een tweede sessie waarin we meerdere Europese providers grondig testen met echte workloads.

Kennisdeling – We willen onze bevindingen publiek delen, zodat ook anderen kunnen leren over de stand van de Europese cloud.

Praktische voorbereiding – Geen overhaaste migraties, maar een strategische positie om goed onderbouwde keuzes te kunnen maken zodra de tijd rijp is.

Europese cloudproviders lopen qua functionaliteit en ecosysteem nog achter op de “grote drie”.
Toch zien we veelbelovende ontwikkelingen: de basisdiensten zijn volwassen, en steeds meer providers breiden hun portfolio uit met specialistische oplossingen.

Wat Europese aanbieders wél bieden, is iets dat steeds waardevoller wordt: volledig Europese hosting met ingebouwde naleving van Europese regelgeving en privacywetgeving.
Het gaat dus niet alleen om datasoevereiniteit, maar ook om voorspelbaarheid en onafhankelijkheid.

Conclusie: voorbereid op meerdere scenario’s

We verwachten niet dat bedrijven massaal morgen overstappen van Amerikaanse naar Europese clouds. Zulke migraties vergen tijd, planning en overtuiging.
Maar bij CINQ willen we voorbereid zijn op verschillende scenario’s:

Klanten die bewust kiezen voor Europese hosting

Nieuwe regelgeving die Europese dataopslag vereist

Geopolitieke spanningen die toegang tot Amerikaanse clouds beïnvloeden

En natuurlijk: blijven waar het nu nog het beste past

De kern is voorbereiding: weten wat er speelt, de alternatieven kennen, en technisch klaarstaan om te handelen wanneer het moment daar is. Of dat volgend jaar is of over vijf jaar – wij zorgen dat we er klaar voor zijn.

Onze engineers onderzoeken Europese cloudalternatieven voor Amerikaanse providers. Lees wat we ontdekten over soevereine cloudinfrastructuur.

EU Cloud: Onze eerste ervaring met Europese cloudproviders

Onze eerste ervaring met Europese cloudproviders

Our engineers recently gathered to discuss a topic that's becoming increasingly urgent: sovereign cloud infrastructure. Our conversation covered cloud solutions in Europe, the Netherlands' digital independence, and our current reliance on American cloud providers. This blog post shares the key insights from that meeting and outlines our planned next steps.

Our discussion began with an observation that's hard to ignore: media coverage consistently focuses on the "big three" American cloud providers - Microsoft Azure, Amazon Web Services, and Google Cloud. While these platforms dominate the market, recent geopolitical developments have raised important questions about Europe's digital sovereignty.

The re-election of Donald Trump has introduced new tensions in European-American relations. While the United States remains a valued ally, our almost exclusive dependence on American cloud infrastructure is becoming a point of concern for many organizations and governments across Europe.

A Real-World Example of Digital Dependency

This concern moved from theoretical to concrete when Trump's administration took action against a Chief Prosecutor at the International Criminal Court in The Hague, blocking access to email services. This was possible because the ICC relies on Office 365 - a Microsoft service subject to American jurisdiction and policy decisions.

The incident illustrates a troubling reality: our digital infrastructure can be disrupted by foreign policy disagreements, even when those disagreements don't directly involve us. When an ally can unilaterally disable critical services we depend on, it raises serious questions about our digital autonomy.

We're not alone in recognizing this challenge. The website european-alternatives.eu, launched in December 2024, has seen a significant surge in traffic (as shown in image below), indicating growing interest in European cloud alternatives. Additionally, cybersecurity expert Bert Hubert a former AIVD supervisor and employee - has repeatedly called on the Dutch government to address this digital dependency.

From Politics to Practice: Time to Nerd Out

While geopolitics sparked our initial interest, we're technical people at heart - so we did what we do best: we rolled up our sleeves and started exploring the technical landscape.

Since we primarily use Azure (with occasional AWS and Google Cloud deployments), we first needed to identify which functionalities are essential to our operations. Given our DevOps team's focus on Kubernetes, the answer became clearer. Beyond container orchestration, we also rely on Azure Functions and various data services. And lastly our CTO still has that Java applet running weekly for €0.01 per month.

After our discussion, we identified these core cloud platform functions:

Networking (public IP addresses, routing, firewalls, load balancing)

Using european-alternatives.eu as our starting point, we found 12 alternative providers listed at the time of writing - a number that continues to grow. Three stood out immediately:

OVH Cloud: Hosted in France and trusted by the French government, now available to public companies. Their established presence and government backing caught our attention.

Stackit: Primarily hosted in Germany and owned by the Schwarz Group (which also owns Lidl). Sometimes playfully called "LidlCloud," this platform has serious enterprise backing.

Cyso Cloud: Based in the Netherlands and formerly known as Fuga Cloud, offering local hosting with familiar regulatory frameworks.

Hands-On Testing: Our Initial Experiments

Our colleague Noud took the lead on testing OVH Cloud's Kubernetes capabilities. The results were encouraging - deploying applications proved straightforward and user-friendly. Using Terraform, he successfully spun up a Kubernetes cluster, leveraging OVH's dedicated Terraform provider to create the necessary resources efficiently.

After deploying a simple nginx application to the cluster, everything worked as expected. The sign-up process was smooth, and deployment times were reasonable. One minor observation: the region naming conventions could be more intuitive, which would simplify initial setup and potential migrations from other providers.

Our colleague Dion began exploring Stackit, though this proved more complex initially. Unlike other providers, Stackit isn't open to the general public - it originated as an internal cloud solution for the Schwarz Group's companies, including Lidl and Kaufland.

Dion connected with Stackit engineers at KubeCon London in April, and we received access just after our session was held. The platform shows significant promise, built on OpenStack for compute, storage, and Kubernetes infrastructure. Their enterprise heritage suggests robust, scalable solutions. We will be testing this soon.

Our CTO Bouke set himself an interesting challenge: migrating his weekly Java applet from Azure Functions to a European alternative. This seemingly simple task revealed some current limitations in the European cloud ecosystem.

While several alternatives offer script scheduling capabilities, Java support remains limited. Other providers require running scripts within Kubernetes clusters, which significantly increases costs for simple, infrequent tasks. This highlighted a potential path forward: adapting to different programming languages to better align with European providers' current offerings.

Based on our initial exploration, we've outlined several concrete next steps:

Deeper technical evaluation: We're scheduling another session in a few months, with teams assigned to thoroughly test each promising cloud provider. This will give us hands-on experience with real-world workloads.

Knowledge sharing: We're planning to make our findings public through an open session, sharing our discoveries with the broader technical community and demonstrating what's already available in the European cloud landscape.

Practical preparation: Rather than advocating for immediate wholesale migration, we're positioning ourselves to support informed decisions when the time comes.

European cloud providers are undeniably behind the "big three" American companies in terms of feature breadth and ecosystem maturity. However, the services we've examined show genuine promise for core functionalities, and some are already expanding into more specialized areas.

What European providers offer that their American counterparts cannot is something increasingly valuable: native European hosting with built-in compliance to European standards and regulations. This isn't just about data sovereignty - it's about predictable, stable access to critical infrastructure.

The current momentum is encouraging, with interesting developments happening at both the technical and governmental levels. However, we're realistic about the timeline ahead.

Conclusion: Prepared for Multiple Scenarios

We don't expect massive migrations away from American cloud providers in the immediate future. Enterprise migrations require significant time, effort, and planning. Political landscapes change, and many organizations are comfortable with their current solutions.

But as CINQ, we're preparing for various scenarios:

Customer-driven moves to European cloud solutions

Regulatory requirements that favor European hosting

Geopolitical disruptions that affect American cloud access

Continued reliance on current providers where appropriate

Discover why sovereign cloud matters more than ever. Learn about Europe's digital independence, the risks of U.S. cloud reliance, and our hands-on tests with OVH, Stackit, and Cyso as promising European cloud alternatives.

Onze laatste blogs

Kubernetes in Europe: Can European Cloud Providers Compete with the American Giants?

November bij CINQ: bekijk de agenda

Ever heard about feathered storage?

17 november: Europese Cloud Meetup

“No pass, no entry” - a musician’s take on JWTs

Onze eerste ervaring met Europese cloudproviders

Why sovereign cloud matters more than ever

Opdracht in de spotlight: Rijkswaterstaat

Meetup door Sysdig & CINQ: AI workshops

Haskell Did It First: Sealed classes and functional programming in Java

Streamline migrations and validate configurations with CriblUtilities