Soverign Cloud. What to look out for?

We heard much of Sovereign Cloud. This term is very new to many and many are also new to the term at the same time like myself. The word, "Sovereign" can means many things from different people just like when the term, "Hybrid Cloud" was introduced.

Let take a look what Sovereign Cloud really meant and what it is meant to address and understand some of the things to look out for.

Sovereignty come with many variable. It can be from hosting location, to the operational of things and also the owning of assets. One of the key sovereignty, is about data. 

To start with, VMware release an article on data sovereignty. Do check it out to understand more. 

In summary, data sovereignty dictates where the data will reside. Whether is it been transported to other places such as replication, and so forth. Should it stays within the land of a countries, if so, replication will be within data centers (AZs) within the counties instead of out.

Though one may be able to achieve data sovereignty, there are still some other considerations whether to adopt complete cloud on premise solution to achieved Sovereign Cloud.

1. Is it fully run and managed by one entity such as AWS, Azure, etc. which is a US company which needs to comply with US regulations. In this case, Patriot Act. In such, hardware, software and operations are all operated under a US headquartered business

Even if you store your data outside of US but the cloud provider who falls under the Patriot Act, then the data can be accessed if needed.

Refer to the Patriot Act.

2. Can public cloud really replace disaster recovery plan?  are you able to meet an application/service SLA just by hosting in the cloud?

Consider this, you might have thought Cloud Providers has Availability Zones, however what if it's a code failure on a cloud service used by a critical application which has an SLA to be up in a short time?  Does a public cloud really able to replace an entire Data Center even for disaster requirement to meet SLA due to regulation or company policy? Can the service SLA meet your requirements? 

With recent news such as the below due to network changes or power outages. It might just cause your critical service to be out of SLA. The statement of "cloud never goes down" is relatively subjective nowadays. So what if it does goes down? The cloud provider will just rebate you credits to utilize more of their services as compensation. Your application resiliency has nothing to do with them. It is your responsibility.

Ref 1: https://www.theregister.com/2023/01/25/network_issues_causing_outage_in/

Ref 2: https://www.datacenterdynamics.com/en/news/data-center-power-surge-and-cooling-failure-brings-down-microsoft-azure-services/

3. Are you using a proprietary service which is only available to one cloud provider?

Consider this, one day if you need to change a provider or move back on premies due to certain reason due to cost, policy, local requirement, etc. you might need to rebuild your app once more.

Perhaps making your application portable and not lock down to a specific service is what needs to be taken into consideration. Example, instead of using an proprietary database type, you might want to make sure that database service is available in other providers or even able to host on premies if a need arise.