In the Dutch news (NOS Journaal) today at 6PM, there was an item about sovereign tech and sovereign cloud. With all the developments in world politics, this has been a huge topic in recent… well, years already I guess. But what that sovereign tech is, exactly, that’s made absolutely unclear by the way media seems to simplify things. Most examples are about email (Microsoft, Google) and cloud (Amazon, Microsoft, Google), and a bit about things like Office (Microsoft, Google) not being hosted in the US anymore. Every once in a while it’s also about social media (which is dominated by Meta and X, but also TikTok.
And I guess that is a good first start. Make sure that the services are based in Europe. And not just having the services there, but also ensuring the companies are European. That already helps a lot.
But back to the Dutch news. The item was mostly about how the Dutch Telecom giant KPN is now partnering with Lidl Cloud to offer a sovereign cloud in The Netherlands. And this is where, to me, the simplification gives the wrong idea. Because by focussing on a collaboration of two huge companies, you give the impression that going to “sovereign tech” is easy: you just switch to KPN and Lidl Cloud.
It’s a good first step. But just as Google, Microsoft and Amazon can flip a switch to turn off your cloud or software, KPN or Lidl could do the same thing. There’s a good chance they won’t do it for political reasons (at least, that’s quite an assumption of course) but it could also be because of for instance commercial reasons. It’s important that to get a really sovereign system, you disconnect from proprietary and closed environments and move to more open environments.
A good first step for your cloud applications is to use containerization. Notice that I’m very specifically not saying Docker, because then you again depend on one specific company. There’s multiple container solutions. The important thing is: If you create container images for your applications, it is extremely easy to switch from one cloud to another. In theory (yes, it’s slightly more complicated) it means just spinning up the container on another server and you’re done.
Another good step is to make sure your data is always present in two places, preferably from two different hosting/cloud providers. In the ideal situation, you have two (or more) servers running so that if one goes down, you can switch to the other, but for smaller setups, it would at least mean to have for instance an hourly backup in another location so recovering your database in another place means spinning up the database, loading the most recent backup, and you’re up again.
For cloud applications but also for desktop applications, it’s also good to rely as much as possible on open source. It’s really hard to “destroy” open source. There’s usually a good community around a project, and a lot of people will have the source code locally, so even if the source code is deleted from the repository, it’s relatively easy to fork (and most licences allow this or even encourage it).
Last thing I want to focus on right now: Disconnect. What I mean with this is to not use too many all-in-one solutions. Yes, it’s easy (and yes, I’m lazy and Ingewikkeld is currently using Proton for email, calendar, drive, password manager etc). But it is better to use open standards and software from different sources. So in the ideal situation you’d have a mail server from one company, use a mail client from another, use the calendar from a third, have your cloud applications somewhere else, DNS in yet another place. You can never fully get rid of single points of failure, but it can make you a lot more flexible when one of the points fails.
The fun thing is: it’s always a matter of learning new things. Even we at Ingewikkeld, and we’ve been working on a lot of the above stuff for years and years, we’re still learning. But the most important thing I can share: Try to stay flexible. Try to avoid vendor lock-in. Use open standards and open source. If a company fails, becomes evil or other weird stuff happens, it makes you a lot more flexible and helps you set up for easy failure recovery.










