Sign up for our newsletter and get the latest HPC news and analysis.

Location independence in the cloud not always a good thing

Interesting post at the All Things Distributed blog about location independence:

For many the “Cloud” in Cloud Computing signifies the notion of location independence; that somewhere in the internet services are provided and that to access them you do not need any specific knowledge of where they are located.

…However for developers to do their job properly the cloud cannot be fully transparent….For example a reality is that failures can happen; servers can crash and networks can become disconnected. Even if these are only temporary glitches and are transient errors, the developer of applications in the cloud really wants to make sure his or her application can continue to serve customers even in the face of these rare glitches. A similar issue is that of network latency; as much as we would like to see the cloud to be transparent, the transport of network packets is still limited to the speed of light (at best) and customers of cloud applications may experience a different performance depending on where they are located in relation to where the applications are running.

This is something that I hadn’t thought about before, and highlights the value of experience in providing these kinds of service.

Comments

  1. Greg Pfister says:

    There’s at least one non-performance reason location transparency cannot mean location invisibility: Geopolitics. It may be illegal for your data to be held in the country where the cloud server resides. For example, certain Canadian privacy laws are apparently in conflict with some US Patriot Act provisions, so Canadian companies should be careful where their servers are located.

  2. Greg – great observation. The US federal government obviously has many concerns in this area as well for their data, and I imagine and some of the Sarbanes Oxley provisions would cause problems for US companies in this regard as well.

    Hadn’t thought of this angle before. Thanks!

Resource Links: