Sovereign clouds don’t exits. We don’t really know what they are. Customers asking for a sovereign cloud have some idea of what they want, but while that may be sovereign (assuming we know what that means), it isn’t a cloud. Consequently, what the market is offering is a plethora of solutions under the banner of “sovereign cloud”. As with what the customers are asking for, these offerings more often than not, are not a cloud. And those that are, are really not that sovereign.
It’s the operation, stupid
The underlying problem is twofold. First, sovereignty is an ill-defined/ill-understood concept in the digital world. Second, the political world doesn’t quite understand what cloud is. As a result, the two worlds aren’t talking the same language and don’t understand each other. Ironically, both worlds make the same mistake: they treat (sovereign) cloud as an infrastructure.
If you look at the NIST Definition of Cloud Computing, it starts with “Cloud computing is a model …” and the details talk about Essential Characteristics, Service Models, and Deployment Models. Only the latter in this list is about infrastructure. Cloud is essentially an operational (business) model and this has far ranging consequences when related to sovereignty.
Cloud infrastructure providers, like the big US providers and the small European providers, only operate the infrastructure and a select set of services. None of these provide all the services your organization needs. In addition, you either need to use services operated by other providers that run on top of those infrastructures or you need to operate your own services.
Juggling third party providers
Databricks and SAP are two good examples of providers that (mostly) don’t run their cloud service on their own infrastructure. You can get their services running on top of AWS or Microsoft, and maybe some others. If you look at this through the lens of sovereignty, the world is now even more complicated, because you are now dealing with two separate operational entities, both of which need to meet your sovereignty requirements.
Let’s for a moment assume that you could operate an infrastructure that is identical to AWS or Microsoft, so you could cut them out of the sovereignty equation. You then need to get Databricks or SAP to operate their software on top of your infrastructure. Performing operations equals having access, which is one of the sovereignty issues we are trying to minimize. Also, these providers need to have trained staff and the more different infrastructures providers need to support, the larger their staffing requirements become, and this gets compounded by requirements such as the location and nationality of that staff. Cloud is a business of efficiency and essentiality sovereign operations is contradictory to that efficiency. And looking at it from the customer point of view, enabling a handful of providers access to your infrastructure may be fine. Doing that for tens or even hundreds of vendors is a vendor management and security nightmare.
Do-It-Yourself Cloud
If you don’t want third-party access to your (private) cloud, you are left with one option: operate it all yourself. That means building your own software, tools, and processes, potentially combined with open source software and third party software you can operate yourself. Essentially everything that is offered as a cloud service by a third party becomes off limits. Are you using Databricks? Switch to plain Apache Spark. Are you using SAP? Run S/4 HANA yourself (as long as SAP still supports this) or build your own ERP. The Cloud Native Computing Foundation provides an open source ecosystem that enables you to build and operate your own cloud services. Building your own cloud on top of that has some legs. But most organizations also run a host of legacy applications that will never run in that environment. These will need to be replaced or rebuilt. And you are responsible for the operations. Are you up to the task?
Sovereignty is about architecture
As I said at the beginning, both the political world and the digital world treat sovereign cloud as an infrastructure. But sovereignty in the digital world as I’ve explained in another article (in Dutch), is really a balancing act between different and sometimes conflicting requirements. With architecture you can do risk mitigations and by combining different cloud infrastructures, such as the ones discussed above, you might be able to cater to different risk scenarios and effectively achieve the sovereignty you want.
