Sovereign clouds don\u2019t exits. We don\u2019t 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\u2019t a cloud. Consequently, what the market is offering is a plethora of solutions under the banner of \u201csovereign cloud\u201d. 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.<\/p>\n\n\n\n
The underlying problem is twofold. First, sovereignty is an ill-defined\/ill-understood concept in the digital world. Second, the political world doesn\u2019t quite understand what cloud is. As a result, the two worlds aren\u2019t talking the same language and don\u2019t understand each other. Ironically, both worlds make the same mistake: they treat (sovereign) cloud as an infrastructure<\/em>.<\/p>\n\n\n\n If you look at the NIST Definition of Cloud Computing<\/a>, it starts with \u201cCloud computing is a model \u2026\u201d 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Databricks and SAP are two good examples of providers that (mostly) don\u2019t 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.<\/p>\n\n\n\n Let\u2019s 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.<\/p>\n\n\n\n If you don\u2019t 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<\/a> 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?<\/p>\n\n\n\n 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<\/a> (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.<\/p>\n","protected":false},"excerpt":{"rendered":"Juggling third party providers<\/h2>\n\n\n\n
Do-It-Yourself Cloud<\/h2>\n\n\n\n
Sovereignty is about architecture<\/h2>\n\n\n\n