Sessie: soeverein en open source dataplatform

Zaterdag 10 oktober had ik de eer om op Data Saturday Holland (opent in een nieuw tabblad) een sessie te mogen presenteren over wat er komt kijken bij het migreren van je dataplatform van Big Tech naar een soevereine, op open source gebaseerde, oplossing.

Tijdens de sessie heb ik de audio opgenomen en het leek me leuk om de transcriptie hiervan met je te delen, samen met de slides en de blauwdruk van de referentieomgeving waarover ik tijdens de sessie vertel. Zowel de slides als de blauwdruk kun je downloaden via de bijlagen onderaan dit artikel.

P.S. De transcriptie, slides en blauwdruk zijn in het Engels, aangezien de sessie ook in het Engels werd gegeven en ik heb hier en daar wat aanpassingen in de transcriptie doorgevoerd zodat deze beter te lezen is.

Opening

Alright. We’ll wait till everyone has found a spot. It’s actually pretty great to see so many people interested in this topic.

We were just having a little chat about it: it’s a bit weird. You have this sponsor slide with a lot of Microsoft-technology-based companies, and then you have this slide. It’s a bit of a contrast. Which, for me, makes it even more special that I’m here.

But also, to immediately give you a spoiler about the session: this isn’t a session that’s going to say all Big Tech is evil, Big Tech is terrible, and you should move away from Big Tech on Monday. That’s not what we’re going to discuss today. It’s more to give you an idea: if you want to move certain parts of your infrastructure, and more specifically your data platform, away from Big Tech, what are the things you need to think about? What can you do, and what are you actually supposed to do? Because it’s not only a matter of choice. Depending on what kind of data you process, in some cases you will actually have to move away from Big Tech.

Who owns your resources?

Before we get started: is there anyone in the room who doesn’t know this screenshot, or hasn’t seen a screenshot like this? It doesn’t have to be exactly the same. Yeah, most people have, right? It’s Azure, a resource screen with all kinds of different services.

But does anyone actually know who owns these resources? [answer from the audience] Microsoft, yeah. We’re going to get back to that extensively.

About the speaker

First of all, my name is Enrico van de Laar. I do a lot of stuff with data. Whether it’s data or AI, I do something with it.

I used to be a Microsoft Data Platform MVP. There are reasons why I’m no longer an MVP; this session isn’t one of them, by the way.

I wrote some books on Microsoft technologies and I founded two companies. We’re going to talk a little bit about the last one, putSimply, because it has a clear link to what I’m trying to tell you in this story.

I also do a lot of training, and I recently started a newsletter, in Dutch by the way, about AI, data, sovereignty and privacy: the four topics I find very important. If you want to keep up to date with the news in that area, you can subscribe on my website.

Agenda

What are we going to talk about in this session? Quite a lot!

We’re going to talk about how we got here: how did we end up in a situation where your data isn’t necessarily your data anymore? We’re going to talk about what sovereignty really means, because there’s a lot of discussion about that word: what does it mean, what does it cover, and especially, what does it not mean?

We’re going to look at building a sovereign data platform ourselves. I actually have a demo where I’m going to deploy an entire data platform on my laptop. I’ll show some architecture as well. And of course we’re going to look at the uncomfortable truth: what is this going to cost you?

We all know Fabric. If you went to a random session here, you’ve probably heard something about Azure, Fabric or some other technology. Most of you probably haven’t really seen a more open-source, sovereign data platform. If we hold those two side by side, at the end we’ll get to a point where we can compare: what’s the difference between these platforms, and what is it going to cost you?

And to make things a little bit actionable, I’m also going to give you some pointers for where you can start this Monday. So you can actually take something home, think about it this weekend, and then on Monday go to your boss and say: “I figured it out. We’re going to do this.” Maybe not that massive, but I’ll give you some pointers.

A regular workday

Before we get started: I picked a random day in the week. If you’re a data engineer, or part of a data team, say as an analyst, your regular Tuesday, Wednesday or Thursday morning depends on a couple of things.

We need to log in to our laptop; for that we have Entra ID. We do our stand-up with the entire team, and that’s in Slack. We use some AI based on OpenAI, or Anthropic with Claude. We look at some dashboards in Power BI. We do some stuff in GitHub. These are daily activities.

What is left if we take out all the American-based Big Tech? Unfortunately, only the coffee. That’s quite a realization when you look at it, right? Thankfully we can still get coffee. That’s good news.

We actually think we have a lot of control over those different things, but in reality we don’t really have that much control.

A question: this Monday, if Microsoft, Databricks, or something in Amazon, wherever you run your data pipelines, decides that your account is blocked: who can run their pipelines this Monday? You just got an email saying your account has been blocked.

Of course it will work, right? Because you’ll run out of this theater, open your laptop and start working to get it to work. But the reality is that in many cases, if you get that email and your account is suspended, there’s not a lot you can do. You’re basically stuck. Your data pipelines will not process any data. That is the reality. Let that sink in.

How did we get here?

How did we get to this point, where we get that email and basically have a little situation? This didn’t happen from one day to the next.

If you go back some twenty years, everyone had their own data center. We had a server rack somewhere in a broom closet that nobody was supposed to open. If you were a big company, maybe you even had two. You had the hardware, you had the servers. You needed quite a big IT department, with people who managed the hardware, who understood how the hardware worked and how the physical networking worked: all that boring stuff.

It turns out that if you’re a big company processing a lot of data, that’s quite hard. You have hardware, you have to make sure the hardware components are maintained, the infrastructure, the electricity, et cetera.

Then we got virtual machines, and around the same time, a little later, we got things like software as a service.

All of a sudden we could host our machine with our software on it on someone else’s computer. We called it the cloud. Our machine would run there, and all of a sudden we didn’t need to worry about the hardware anymore. We didn’t need to worry about the power; we still had the power for the laptops and desktop PCs, but not for the servers in the server room.

After that, a couple of years ago, a lot of integration started happening. I remember that when Azure first became available in Europe, it was a lot of separate components that you had to tie together yourself. But if you look at current data platforms like Fabric, everything is fully and seamlessly integrated: security, logging, auditing, networking, permissions. Everything is integrated in this one platform.

So if you now say, “I don’t like this authentication provider in Azure or Fabric, I want to use another one,” it’s not going to happen, because it’s fully integrated. Which also means that with each of those steps, it becomes harder and harder to move away.

When we still had virtual machines, you could say: whether the VM runs in Amazon, in Azure or on Google doesn’t really matter, I can run it anywhere. But now that we’re moving to fully software-as-a-service data platforms like Fabric and Databricks, it becomes more difficult. We’re losing a bit of control in that area.

Three things we can’t control

Speaking of control: there are actually three major things that we, as European organizations, cannot control, no matter how hard we try.

The first one is immediately one of the most important ones. I don’t know if anyone has ever heard of the CLOUD Act? A lot of people know about it. Basically it means that every American company, if the American government requests it, will have to hand over data, disable services, or do whatever the American government thinks is required.

One of the things I usually hear is: “This is no issue for us, because we have all our data in West Europe. It’s in Amsterdam, they can’t touch it.” That’s not true. As long as the place where your data is hosted is owned by an American company, even through a subsidiary or whatever, it still applies.

As a matter of fact, a couple of months ago Anton Carniaux of Microsoft France had to declare under oath that if the US government requests data on European citizens from Microsoft, he has to provide it. He declared under oath that this is true. So this is not something I’m making up; this is actually the case. If you have sensitive personal data inside an American hyperscaler, you kind of have to take it out. Right now.

In the last couple of years, relations between the American government and European organizations have been a little bit on edge, to say the least. I believe yesterday the President of the United States declared that we are no longer allowed to say “artificial intelligence”; it should now be called “superintelligence”. Which fits the line of rebranding he does. That guy can basically decide what’s going to happen.

One of the examples that hit home, especially here in the Netherlands, is that at the International Criminal Court in The Hague, the mailbox of the Chief Prosecutor was suddenly disabled. It was an Office 365 mailbox. We don’t know the exact details because they’ve never been published, but what’s interesting is that they’ve now moved away from Microsoft entirely, to another provider. So there was probably some reasoning there. And I read in the Dutch news yesterday that Trump is planning to put even more restrictions on the International Criminal Court. So they’re actively planning to abuse American government power and perhaps tell Microsoft: you need to do something for us again.

And again, this is not Microsoft being bad or evil or whatever. They have to comply. There isn’t a choice. They can’t say “we’re not going to do it”, because then they’d basically go bankrupt.

Another thing that hits home even more directly: we’re not negotiating with American hyperscalers. We’d like to think we are, but when I got an email a couple of days ago saying Azure VM prices are going to increase by 7%, I can’t call Microsoft and say, “Okay, let’s talk about it, let’s make it 5%.” You either comply, or you move away. It’s nice that there’s a contract, but it’s one-sided. If a hyperscaler decides something, they know the power they have.

We did try to get back control

Now, if we know all this, you might look at it and think: this is kind of strange. But it has been this way for quite a long time. And we, and by “we” I mean Europe, have already tried to do something about it. I don’t know if anyone knows it, maybe if you’re more into legislation, but there’s a famous saying: America innovates, China replicates and Europe regulates.

So we’ve been trying to regulate this. From the 2000s we actually had quite a good regulation on it, called Safe Harbor. It basically meant that during that period, American companies promised it would treat data and services from EU companies and citizens as if they were hosted in Europe. However if the American government said “you need to hand over this data”, they would still have to comply.

There were, however, some major legal issues with these agreements (I won’t go into the details), which is why they got struck down. So right now we’re talking about the Data Privacy Framework and trying to see whether we can get that to work. But it takes a long while to get this under control, and seeing all these previous attempts, I’m not really sure we’re going to fix sovereignty through legislation. So what can we do instead?

What is sovereignty?

Let’s start talking about sovereignty. This is the official political definition. Which, honestly, is a little bit too much and it sounds quite heavy. But this is how it’s used politically: you’re a country if you comply with these kinds of things.

In our case, we’re mostly looking at the control part. As an organization, you want absolute control over your data, the data you process, and the services you have. That’s something we all want. That’s what we’re aiming for.

Basically, this means that if we want to take back sovereignty and take back control of our data and our data platform, we should always be able to ask ourselves three questions:

1. Who can access the data we have in our organization?
2. Who controls the services of, for instance, our data platform? Who can switch it off? That’s an important question.
3. Who sets the terms? Think of the license agreements: can we negotiate with them, and how much do they control us?

If you look at those questions and this definition, even though it’s a bit much, and you think, “Okay, then I’ll just move to a European cloud” (there are plenty of other cloud providers doing cool stuff), or “I’ll ask a Dutch company, a private cloud provider, to host my service,” you still have the same issue in some situations.

Because as long as they’re able to turn off your platform or they control your terms, for instance you can’t say “I want to swap this part for that part” and they say “no, sorry, you’re already in our stack”, you have the same problem. Only then it’s not the hyperscaler, it’s your local cloud provider.

It’s the same if you use specific software from a single vendor. If your business depends on a vendor that controls the terms, and you can’t switch to a competitor because of those terms, you’re still locked in. So it goes way further than only a bit of data and a few services.

To realize a truly sovereign data platform, we have to take back that control.

Four layers of sovereignty

If you look at sovereignty at the data platform level, there are basically four questions you can think about.

The first one is, of course, your data, because your data is the most important thing your organization has. You want to know who can read your data and who can access it. Those are the basics you need to cover. And how quickly can I move my data from one service to another? That’s control at the data level.

Then there’s your operations. There’s an issue there too: who can turn it off? Say you have full control of your data, but it’s being managed by a third party that can say, “We’re going to switch it off tomorrow.” Then you still don’t have control. So you need to figure that one out as well.

Then you have the technology. What if I don’t like this partner, this hosting provider or this solution anymore, at whatever level, and I want to move it somewhere else? Can I do that? Do I have enough control to say on Monday, “Let’s grab everything we have, move it somewhere else and run it from there”? Next Monday is a stretch, I know, but there are situations where you actually need to.

And if you want to go really, really far into sovereignty, you also have to think about the supply chain. Who makes the parts your servers run on? Because, silly enough, there have been a lot of situations here in the Netherlands and all across Europe where we discovered that certain switches leaked information about network traffic to other countries. So this can go really, really far.

If you look at the whole picture, at true sovereignty, you have to think about all these things.

The European Commission’s Cloud Sovereignty Framework

Thankfully, we’re not the only ones thinking about this. The European Commission built something called the Cloud Sovereignty Framework. It was introduced in October 2025. Has anyone ever heard of it? A couple of people, yeah, that’s quite good.

What they basically did is grade vendors and solutions on a number of levels. It starts at SEAL level 0. SEAL stands for Sovereignty Effectiveness Assurance Level: how sovereign is your data if a solution is in this tier?

Level 0: there’s basically no sovereignty. This is the situation where all your data is on Amazon, on American servers. Everything’s there, you have zero control over the data, and it all resides outside European borders.

Level 1: things are slowly improving. This is where a lot of us are: we use Azure services, but we deploy everything in West Europe. Even though Microsoft is an American company, our data is in Europe. That’s SEAL level 1.

Level 2 means that everything should also be controlled from within Europe. What they mean is that even if you still host your services with Microsoft and your data is in Europe, only European citizens manage your infrastructure. So no non-Europeans managing your infrastructure. At that level (two, sorry) you also have a European control plane. I mention Microsoft a lot, right, but it’s the same for Amazon, for Google, for all of them. Microsoft is just the most familiar, I think.

At level 3 there’s also the situation where you use a partner. That’s what a lot of the American companies have been focusing on. They said: “We’re just going to start a European company, founded in a European city. We’ll only hire Europeans. It will be a fully European company,” but it’s still a subsidiary of Microsoft in America. That’s level 3: you have a legal entity inside Europe that hosts data and services.

Then we also have level 4, which is only a theoretical level. Level 4 is the ultimate European sovereign solution, because then all the supply chain components would also be European-built. We do produce network switches in Europe, but not at the level of non-European ones.

Now, if we look at this official-looking chart, most of us are here. Would you agree? I think most people are sitting in this area: we have our data and our services in Europe, with Microsoft.

Microsoft can actually span a lot of these levels, from level 1 to level 3. The only issue we still have with Microsoft at level 3, and it’s actually an important one, is that they still determine the terms of our license agreement. They set the license terms we have to comply with. And that’s exactly one of the aspects of sovereignty we want to keep in our own control. You don’t want to depend on someone who just says “prices are going up” with nothing you can do about it. And nobody is at level 4 yet.

Sovereignty is a dial, not a switch

What’s important here when I talk about sovereignty, and you can see it in the title as well: it’s a dial, not a switch. It’s not like, “You know what? We’re going full sovereignty mode on Monday.” That’s not even needed. There are plenty of cases where you can say: depending on what kind of systems and what kind of data I process, I’ll pick where I host it.

Public-facing content, like your website, you can easily host somewhere where the data is in the EU, even if you don’t have control over that part. It’s the same if you use Office 365: if you’re not processing sensitive data and your business doesn’t depend on it (that depends on your company, I guess), it’s probably fine to just host it in Europe. It could probably work.

But if you have safety-critical systems or very sensitive data, you don’t want to be in any tier lower than three. And even then it’s tricky, because Microsoft still sets the terms. But in terms of data and control, it’s the best you’re going to get, unless you build it yourself and host it yourself.

So again, it depends on the workload. Like I said at the beginning, it’s not all or nothing. Like everything, it depends on what your workload is and where you want to host what.

Principles for a sovereign data platform

We’re going to build a sovereign data platform, and I’m going to show you the one I designed and built. For that we need a couple of principles, because we’re diving into architecture. And if you’re an architect, or you have an architect colleague, they’ll ask: what are the principles?

These are the ones I looked at for my sovereign data platform. Nothing too complicated.

• Data in open formats. If my data is in an open format, I can move it anywhere; I basically have full control over the data. And I can read it with something I didn’t buy. To give you an example: if you put your data in an Azure SQL database and you want to move it, you have to do an export. If your data is in a CSV file, you can open Notepad or any other tool and still read the data. Parquet is also a very good example, but I’m saving that for later; we’ll get to it.
• Replaceable storage and compute. If there’s another solution that better fits the goals, I want to easily swap out both the storage solution and the compute. This is actually very important, because if you’re going to build a sovereign data platform, you’ll rely a lot on open-source technology. And open source is a gray area. License terms can change, and it could very well be necessary to move from one solution to another very quickly, because a developer says, “Oh, I just sold everything to Amazon.” So there’s always a risk.
• Own identity management. Identity management cannot depend on another service. I don’t want anyone to be able to disable a user’s or an employee’s access to my platform.
• Easy to migrate the entire stack. I don’t want to have to migrate service by service; I just want to pick everything up, lift and shift, and move it.

Open source is not a principle

To reinforce the point I just made: open source is not a principle. The reason is that it can change, sometimes very quickly, and often there’s not much you can do about it. Terraform, for instance, which a lot of people know, started out fully open source, but it isn’t open source anymore. Same with Redis, same with Elastic. Those licenses change, and you have to be prepared for that.

The key check if you use open source: you always have to know who controls it and what happens if something changes. There’s one situation where you’re basically always good with open source, and that’s foundation-based open source. Software released by the Apache Foundation, for instance, will always remain open source. So if you use those solutions, and I’ll show a couple, you’re a little bit safer.

The reference architecture

Knowing this, let’s look at what a sovereign data platform can look like.

Let’s start at the bottom. Infrastructure, hardware: we don’t have European-built hardware, but on it we can host Kubernetes. As you’ve probably figured out, you need to do something with containers. That’s the only infrastructure where you can say, “Let’s swap this component for that one, take the whole thing and move it somewhere else.” You can only do that with containers: with Kubernetes, Docker or whatever alternative there is. So if there’s one thing that’s certain: if your organization is thinking about this, about moving to something more in your control, or less dependent on American hyperscalers, you will have to do something with Kubernetes.

So, next to what we’re going to do this Monday: you still have an entire day tomorrow to learn Kubernetes. It’s easy. Everyone understands it (this was meant as a joke 😉).

Object storage. We need to store our data somewhere. We already said Parquet is a good idea, and it really is, because it’s an open format. So we need an object storage layer. In this case I went with SeaweedFS, an open-source, S3-compatible, bucket-based storage layer. On top of that we need an open format: that’s Parquet, together with Apache Iceberg.

And then the catalog: basically our catalog and our table format. This is also to separate the different services. The processing services and the query compute, the query engine on top, go through the catalog to figure out where the data lives.

The nice part is that you can basically move your data away, change the pointer (“hey, my data is now over there”), and your query engine will keep running. If I swap Trino for DuckDB on the fly and tell DuckDB “this is my catalog”, everything on top of it keeps running, because it’s loosely coupled. They don’t necessarily know where the data is, but they know how to access it. That’s one of the big advantages.

[remark from the audience about Amazon acquiring DuckDB in September] Yes, that’s a very good remark. DuckDB, the company, was bought by Amazon in September, but not the solution. The DuckDB engine is still MIT-licensed and will remain open source under MIT. So you can still use DuckDB; only the team, the people, were bought by Amazon. What this means in the long run is, of course, a question. Because what if they say, “We’re going to stop development on DuckDB”? You can still fork it and do your own development, but if they decide not to develop the community edition anymore, yeah… But for now it’s still MIT.

To complete the stack in terms of consumption, instead of Power BI I’m of course using Apache Superset.

And these are just a few open-source technologies. At the end I have a QR code that goes to my GitHub. There’s a blueprint document where, for each of these layers, I looked at between five and ten alternatives. So there are plenty of other open-source solutions.

You’ll notice a little star behind the processing layer. Those solutions are open source, but they’re maintained by a single company. That’s a risk. If the company decides to stop development, there’s not a lot you can do. Maybe you can fork it and develop it yourself, but I don’t think a lot of companies would actually want that.

That’s an argument a lot of open-source people use: “If they stop developing DuckDB, we’ll just fork the repository and do it ourselves!” I don’t know if you’ve looked at the DuckDB codebase, but you’ll need very experienced developers to continue developing that.

To make things complete: for the data platform we also need orchestration, some ETL work, and for that we use Apache Airflow. Another Apache project. And for identity we use Keycloak. Especially for identity, there honestly aren’t a lot of choices.

The control plane: everything is now your responsibility

There is, however, one little issue with this entire platform. We need something we’ve already discussed to manage all of this, and that’s what we call a control plane. We need to manage all these solutions.

With Fabric, the control plane is integrated into the solution. We all know Fabric is really just a collection of different Microsoft services, right? Underneath it’s still just Data Factory, and they sell it as one product. But what they’re actually selling as one product is the control plane. They do this for you.

In our case, it means everything is now your responsibility, or your colleague’s. You have to worry about running updates on your Kubernetes cluster, upgrading the container images, identity management, backups, disaster recovery, monitoring, compatibility. Because that’s not easy. It took me a while to get this all working, because even between different open-source solutions there are compatibility issues. Not everything talks nicely to each other. It definitely takes some effort.

And this is what you’re now getting almost for free, because this is what the hyperscalers do. If you look at a hyperscaler offering after today, you might think: “Technology-wise, I can run everything myself; that’s not going to be an issue.” But who is going to do my 24/7 security monitoring? Who is going to do my disaster recovery? Who is going to do my compliance certifications, for instance? And where am I going to find readily available, skilled people?

It’s not a technical problem, it’s an HR problem

Because the main issue with this, and it’s one of the trade-offs (it’s not all glorious): it’s not a technical challenge anymore. Moving to a sovereign, open-source-based data platform is an HR issue, not a technical issue.

I’ve shown you that you can do it. You can discuss certain functionalities, whatever, but it’s available now. You can do it if you put in the effort. But you need a very particular set of skills (I’ve heard that line before in a movie) to be able to actually deploy and manage an environment like this.

The annoying thing is that there are a ton of people who are Microsoft Certified Fabric Administrators, but finding one person who knows everything about Kubernetes is like looking for a needle in a haystack. And if everyone is going to build their own sovereign data platform, everyone is looking in the same haystack. So it becomes more competitive.

There is of course something we can do about this: learning new skills, not being dependent on one technology or one vendor. But it is the biggest risk here. You need the people to make this work. You need the skills to make this work. So it’s not the technology.

A change in expenses

It’s also a shift in expenses. For the people who look more at licensing and costs: I’ve got you covered, I have a slide for it.

With a hyperscaler, you’ll see that infrastructure costs are a little bit, people costs are a little bit, but license and usage costs are a lot. Why are people costs only a little bit? Because you probably need fewer people to manage it, and because the hiring pool is bigger. I’m pretty sure that on a day like today I could easily find ten Fabric experts to hire for Monday. And because there’s so much supply, I can say, “I’m only going to pay you this.”

If you’re the Kubernetes hero, the overlord who knows everything about Kubernetes, you’re going to ask for a lot more money. Which you should, of course, because those skills are scarcer.

If you look at a more self-hosted, sovereign solution, you’ll see that infrastructure costs are a bit higher, because you pay more for the hardware and so on. But your main expense is going to be people.

So if anyone tells you, “We’re going open source because it’s cheaper”: it’s not cheap. You need different skills. It’s not necessarily cheaper. It can be cheaper; there are examples of organizations that did move away and now actually pay a smaller bill. But that also depends on your team.

In that sense, I don’t think the cheaper argument matters much, because you’re not out to buy a cheaper platform. You’re out to get a platform that’s in your control and stays in your control. Even if it’s a bit more expensive, that shouldn’t matter, because if you go this route, the whole organization has probably already decided that this is the way to go.

The putSimply use-case

Like I said, I’d tell you a bit about a startup I’m involved in, called putSimply. Very briefly: we’re building an app that lets people scan a letter or an email, or take a picture of a text, and simplify or translate it to their own personal language level. We’re doing this because one in five people in the Netherlands has low literacy. And unfortunately our municipalities and healthcare organizations keep sending letters that are way too difficult for these people to understand. So we decided to make an app to solve this.

What we did for putSimply, and this was not the easy route, is that we only use European hosting solutions for our backend. We do everything with Scaleway, a French cloud provider. We have a Kubernetes cluster there. It’s hosted here in Amsterdam, but owned by a French company.

For our office solutions, we still communicate through Teams. We chose that because we don’t send sensitive data through it, like what the users of the app are scanning. We could already imagine that if you build an app like this, people are going to scan the letters they get from their hospital, et cetera. So we have to take measures to protect that privacy at the highest level.

We also use open-source or European language models. We do a lot with Mistral, self-hosted. Maybe not the best model, but good enough for our case.

The app isn’t available yet, by the way, for anyone looking; it should be out sometime next month.

So we could do it, but we have the advantage of starting fresh, and we had people who already knew a lot about this topic. So for us it’s a bit easier, because we already had an important part of the skills. But even we struggle every now and then. It’s not easy.

Where to start on Monday

Finally, some tips on how to get started. Because hopefully I’ve inspired you, and you’re thinking, “I can’t wait to start building my own sovereign solution on Monday.” It doesn’t have to go that far right away, but this is what I’d recommend to everyone:

1. Take inventory. A first step that costs zero euros: just figure out where your data is. Where are your services? Who controls them? What are the licensing agreements? Can you change any of that? Just an inventory of all your services.

2. Use open formats. Also a relatively easy step, which you can easily take in Amazon, Azure and all the other platforms: instead of putting all the data for your next project in yet another Azure SQL database, why not try storing it in Parquet files, in a lake, for instance? If your data format is already portable, you can always say, “When the day comes, we’ll move our data out.” It’ll be a lot easier. You don’t have to migrate from SQL to somewhere else. So with a new project, don’t deploy another database; see if you can do something with an open format that makes it migratable. Just try it out.

3. Play out scenarios. I always like to play those role-playing games with my colleagues. Have a chat about what happens if someone says, “The sysadmin’s account will be blocked tomorrow.” What’s going to happen? I’m pretty sure there’s an account somewhere that everyone forgot is used as the GitHub administrator account, and when it’s blocked you can’t add another administrator, and all that kind of stuff. Those are the things you need to figure out. It’s free, you can try it out, and at least you’ll get a picture of which areas you’re kind of locked in. So that when the question comes, you’re prepared.

Signals from The Hague

And I read some very good news yesterday, especially for all the Dutch people here. The Dutch Tax Administration was going to move to Microsoft, but yesterday the new minister decided they’re not going to do that anymore. They’re going to build their own solution and host it locally. I do have some worries about this, but at least it’s a clear signal, right?

The other side of the coin: if you’re interested in this topic, I don’t know if anyone knows Bert Hubert (opent in een nieuw tabblad)? Yeah, okay, you know him. Bert Hubert is a self-proclaimed nerd. He follows a lot of sovereignty talks and a lot of debates in government. And he says the sad thing is that there are a lot of politicians who are very willing to move to a sovereign solution, but there’s no money.

So hopefully: we already have the will. If we can sort out the money, and find the people as well, maybe good things can happen over the next couple of years.