Digital sovereignty means a lot of different things to different people and unfortunately the debate is dominated by the simplistic view that sovereignty is a single dimension problem that is fixable by taking control of everything. Christophe Fouquet, CEO of ASML rightfully tells us this is unrealistic:
“Everyone would have to find a balance between this huge claim for sovereignty … ‘we want everything to be done in our country’ … and the reality, which is: this is a fairly spread ecosystem, with key elements in different places,”
And there is an underlying reality as well: it’s not always good to do things in your own country for a variety of reasons, ranging from economically not viable to literally impossible because you don’t have the resources. This means we need to shift from controlling everything to controlling what is needed and not controlling what is acceptable not to control (which can shift under different circumstances). Or put in a different way:
Sovereignty is a spectrum, not a switch, and we need to be able to move on that spectrum.
The “red button” and war
In Europe we’ve been hearing about the so called “red button” that the White House supposedly has to turn off all cloud services in Europe. I will not delve into why this red button doesn’t really exist and just acknowledge that it has been a catalyst in the desire to build cloud infrastructure in-country. As the war in Ukraine showed us several years ago, and the war in the Middle East is reminding us today, in-country infrastructure can be physically attacked and potentially destroyed. Underneath these two examples lies a business continuity challenge that shows us we need to be flexible to act in different scenarios. Where in-country infrastructure is a good idea for one threat scenario, it isn’t for another.
Vendor lock-in
Vendor lock-in diminishes the very flexibility we seek and the typical answer to this challenge is “use open source”. However, like the in-country infrastructure is a solution to particular threat scenario, open source solves some problems and introduces others. For one, it shift some of the operational challenges from vendor to customer. That isn’t necessarily bad, but you do need to understand what you’re signing up for. For example, mitigating software supply chain risks is pretty complex, especially if you have a relatively small team of experts.
It’s the operation, stupid
I’d argue that what we really need is flexibility in how we deal with operational concerns. We can leave operational concerns to a cloud provider under most circumstances, but we want flexibility to move from one provider to another and be able to take care of operational concerns ourselves if needed. And yes, open source does play a role in that for core components, but that doesn’t mean everything needs to be open source.
The building blocks of flexibility
We already have an open source compute layer provided by container technology and Kubernetes. However, as most people that use this technology know, you rarely just use compute. You typically need storage, databases, messaging, and other capabilities and these tend work slightly differently in different platforms. So using containers and Kubernetes only gets you half way there.
A quick conclusion could be that you should also only use open source storage, databases, and so on, but that could mean you can’t use best in class or fit for purpose technology or worse still, your application isn’t flexible enough to run on any platform. Fortunately, there is a better solution. There are two Cloud Native Compute Foundation projects, originally developed by Microsoft, that enable you to make your applications flexible, so you can move them from one platform to another. The first is Radius and the second is Dapr.
Radius
Radius enables developers to tell which services they need, for example a PostgreSQL database or a Redis cache. It is up to the platform team to provide these capabilities in platform that the application needs to run on. Radius enables the creation of recipes for different (cloud) platforms, that spin up the required services and enable these for the application. As an analogy, you can think of Radius as a taxi service. You don’t worry about which car gets you from A to B, you just tell it where to go.
Dapr
Dapr adds another layer of abstraction that makes enables even more flexibility. Developers can tell which type of services they need, such as a database, a cache, or a messaging system, and the platform team can provide those services with different types of technologies, as long as these meet the requirements of the application. To extend the Radius analogy, think of Dapr as a travel agency. You just have to say where you want to go and the agency books the transportation for you, which could be by car, bus, train or plane. This enables moving from one underlying technology to another, for example when newer and better technologies become available or a target platform has a different way of providing a certain services (e.g. AMQP instead of MQTT).
Conclusion
Sovereignty is “just” one of many requirements and we need the flexibility to weigh different requirements against each other and make adjustments as the world around is changes. We do this by making applications flexible and the building blocks to do so are there, we just need to start using them. That doesn’t solve all our problems, because we also have to be able to move or replicate data, but that is a subject for another time.
