Cloud Computing Business Considerations - Dealing with Data Center Placement

In this article I will consider where geographically you might want to host your cloud-based systems. The world’s a big place and for many organizations deciding where to host systems is a complex issue - with or without the cloud. For commercial convenience organizations tend to break the world down into three areas – the Americas, EMEA and APJ; I'll use that same model.

Coverage in the Americas

It is fair to assume that if you placed a data center into the central USA then you’d be able to offer decent coverage to 80% of the commercial opportunities in the Americas region. You would not be geographically central but you would be close to the majority of the opportunities in the region; that’s the reality of the distribution of commerce across the landmass. Place 2 or 3 datacenters throughout the region and you will have pretty much the entire area sown up.

From a compliance perspective many customers in Canada and Mexico are willing to tolerate a US-based data center when their local regulations allow.

Coverage in EMEA

For EMEA you have a similar model; place a data center in mainland Europe and you can probably offer your service to the majority of the region’s commercial opportunities. Again, distribute 2 or 3 data centers in EMEA and for sure you have cornered the market. I get that Johannesburg is a good 6,000 miles from Helsinki but commercially the key opportunities are centralized around mainland Europe. The EU has also passed a number of regulations to manage the distribution of content between countries. 

Coverage in APJ

APJ brings its own set of challenges. Like EMEA and the Americas it covers a vast area from the southern hemisphere to the north. However unlike in the the other regions, in APJ the distribution of commerce is more even. So placing data centers in 2 or 3 locations does not give you the 80/20 coverage that you might see in the other regions.

More of an issue than the geographical distribution of commercial opportunities is the lack of unity between the countries. In the European Union there are laws that allow for the sharing of protected data between member countries, in many cases this might allow for a centrally located data center to host systems used across many countries. In APJ the story is very different:. A company based in one country may legitimately refuse to have their data stored in any neighboring country because they want to have certainty around who has access to the data and they cannot control another country’s laws/administration.

I started writing this article on a flight back from Hong Kong. Hong Kong is part of China albeit they call it a SAR (Separately Administered Region). I asked whether the customers based in Hong Kong would use a China-based data center. The answer was “absolutely not”. I asked whether Taiwanese customers would use one in a China or Hong Kong – “nope”. Japan using Singapore? India using Australia? Australia using New Zealand? No to all… The only concession that I heard was that some of the customers based in southern China regions might consider using a Hong Kong-based data center but not those based in the northern regions ;-)

Similar issues also exist in EMEA and the Americas with specific content types and specific regulations where data needs to be kept locally but it is less common.

So, what’s the solution?

Change the laws/regulations/perceptions

The truth is that many of the regulations that we are trying to adhere to were not written with today’s distributed architectures in mind. No one was thinking about accessing systems from smart phones, desktop virtualization, delivering anything “?aaS”. In fact many of the regulations were focused on access to physical assets not electronic distributions. These laws need to be cleaned up and made relevant to today’s technology. We need laws that protect data adequately in a way that can actually be implemented and monitored at the scale that we see today.

Have local deployments

The reason that non-cloud deployments do not worry about these issues is that the systems, the data and the staff are typically all deployed within a single country. So, if your cloud service provider will guarantee that your systems and data are in a cloud data center in-country then you are no worse off than with a local deployment.

This is often not the case, especially with the larger more ’generic’ providers. However, some cloud service providers (I should in good conscience mention that the EMC project I am working on does support this model) will allow the systems to reside in a local datacenter or even in your own datacenter. You might wonder how this can be a cloud solution if it is not “out in the ether” in a multi tenant environment? A local, single tenant instance of a system certainly loses some of the features of cloud deployment but it can retain some of the key ones too. Assuming that you host the cloud solution on a shared physical stack you can still get elasticity associated with a shared infrastructure through virtualization. If the cloud service provider will still manage the system remotely and provide the system as a local “black box” then this might be a compromise worth considering.

Use technology to protect

Let’s take a different tack. What does the regulation really say, or really mean? Let’s say that the data was physically stored in a different country but could not be accessed by anyone there. Would that satisfy the intent if not the letter of the regulation. If you stored your data in an encrypted form and only allowed the decryption to be done by people within your home country then you might be able to meet the actual requirement. Digital Rights Management (DRM) would allow for this out of the box today.

Another advantage of DRM is that it protects data in the cloud but it also protects it when it is taken offline. If you download a DRM protected document to your smart device the local application could in theory still protect it…imagine, it could do a quick retinal scan to identify you, look at the GPS coordinates to see where you are and then decide whether to give you access. Orwellian or what?

Don’t use the cloud for that type of data

The reality is that today the cloud is not a panacea for all content, in all cases, in all locations. In five years it will be the de facto delivery system for most applications but maybe not quite today. You might decide to keep certain systems locally for now until things mature. My advice however is not to throw the baby out with the bathwater. Just because some systems might not move into the cloud today doesn’t mean that you cannot move others. In fact, take the opportunity to offload the less critical systems into the cloud and focus your management efforts on the remaining systems.

Conclusion

You are going to have to be creative and flexible if you are concerned about any of these issues. These boundaries exist because of infrastructure, physics, lawyers and politicians. Infrastructures will evolve, physics can be manipulated (we almost had Neutrinos traveling faster than light recently) but the lawyer/politician thing isn’t going to be solved any time soon.

Truthfully, this is just another indication that the cloud is still maturing. It is growing up much faster than the surrounding practices, laws, regulations and culture These growing pains are going to be a challenge for a while longer...

Comments

[remote desktop]

You’ve pointed out some excellent solutions. I particularly agree with your last point – “Just because some systems might not move into the cloud today doesn’t mean that you cannot move others.” A very well-written article, good work.

[DynTek]

Geography can be very important when identifying the right data center location to channel information through. Things like weather patterns and natural disasters are important to consider also.