SQLServerCentral Editorial

Data Sovereignty Issues

,

Many people think about the cloud for cost reasons first, often because they can transfer the expense from a capital to operating budgets. Others think about the flexibility the cloud vendors offer to spin systems up and down, change configurations, and adapt to requirements quicker than many internal groups can. A few consider scalability, where we can grow or add systems to meet our needs.

What about data sovereignty? I ran across an article recently that talked about the new SAS cloud on Azure, but located in different places for different reasons. Customers in the EU can use the German version of this. Those customers in the UK, because of Brexit, might choose the UK data center.

It's an interesting idea, where we might not think about just which specifications and services we use, but where they are located. That can pose challenges for architects and software developers, who may need to route customer requests to different data stores, based on their location. I'd think this is easier for database professionals, as we just duplicate stores in different places.

This does mean that we'd need to manage backup, integrity, ETL flows, etc. in multiple locations, and we'd had the need to roll some data up across different data connections, but technology is making this easier all the time.

The legal requirements and protections of having data in different places are still being argued and worked out. Microsoft fought a battle, and there was some resolution for how to handle cross border data issues, but I'm not sure this is settled law yet. Time will tell, but if there is any value to customers in where data is located, I suspect some of us will need to consider how we store data in different physical locations.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating