Skip to main content

(Part 1) Things that we should consider when the content stored in Azure shouldn't leave a specific country

Part 1 - (Part 1) Things that we should consider when the content stored in Azure shouldn't leave a specific country
Part 2 - (Part 2) Things that we should consider when the content stored in Azure shouldn't leave a specific country

In this post we will talk about what is happening with data that is transmitted between Azure Regions and on-premises systems.

Context
Nowadays, Microsoft is opening more and more data centers around the glob. Regions like Japan, UK (to be announced), Brasil, Germany, Korea are already in-place or will be in-place soon.
This specific countries have laws that requires for specific industry or data to not leave the country. Especially in health-care industry it is common to have a restriction that patient information to not leave the country in any moment in time. Similar laws are for other industries like banking or data protection.
In this context we need to be aware of this laws, what kind of solutions we propose and what is happening with the content that is transmitted between Azure Regions and on-premises systems.

The main purpose of this article is to cover what is happening with content that is transmitted between Azure Regions and on-premises system and things that we should be aware. Another article will cover about different configuration of our Azure Services that might affect us.

What is happening with our data inside an Azure Region
Assumption: We don't take into account different Azure Service configurations that might move data to another regions. We assume that customer didn't configure the Azure Service to back-up or replicate content in another Azure Regions. 

All the data that we store in an Azure Region will remain in that region. The content that it is stored in a specific region will not leave that region. This means that we can store data in UK Azure Region without any kind of problems. The content will not leave UK Azure Region by magic and to be stored in another region like Germany.
If Azure Regions from that region have technical problems, even going down, our content will not leave that specific country - or Azure Paired Region (based on Azure Services configuration).
A very useful table can be found on the following link, that specifies the paired region for each Azure Region - https://azure.microsoft.com/en-us/documentation/articles/best-practices-availability-paired-regions/. As we can see in the above link, Japan East is paired with Japan West, same country  just another location. There are some exception, that will be covered by the next article.

What is happening with our data when it is send from/to Azure Region to on-premises systems
This case is generic for any cloud provider and not specific to Azure only. 

All the content that is send by wire from an Azure Region to an on-premises system will go through local ISP's (Internet Service Providers), from that specific countries. This means that content will not leave that specific country as long as the on-premises system is in the same country as Azure Region.

The things become a little more complicated when data goes from one ISP provider to another and so on. We can have ISP providers that might detect that the load on a route that leaves that country and comes back on is better than the one that we have in current country. In this case they can decide to use another route. This means that during the transportation, the content will leave the country. This case can happen inside the same ISP, depending on the routes load and how the balancing is done.

A similar thing happens when for example a main route or a big local ISP provider is down and content is redirected through another routes. For example even if we have a dedicated connection, for example between continental Spain and Grand Canary Islands (that is part of Spain), if this is down data might flow through other routes like Egypt or UK (countries are given only as an example). This means that even if we have a dedicated connection, the content might use another route and leave our country.


For this scenarios, you don't have kind of control. If you have enough resources, you can construct your own line between them, but this is expensive. We should remember that at transport level, we don't have any control on how the ISP sends the content and how the routing is done.

Conclusion
As we saw, controlling the data to not leave a specific Azure Region is easily and can be controlled as Azure Services level. At transport level, things are more complicate and there is no way how you can guaranty this without a dedicated line or custom contracts with ISP providers (when possible).

Part 1 - (Part 1) Things that we should consider when the content stored in Azure shouldn't leave a specific country
Part 2 - (Part 2) Things that we should consider when the content stored in Azure shouldn't leave a specific country

Comments

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…