Simply put, “location independence” means that a user or customer should be able to access the cloud service ubiquitously and responsively regardless of his or her location. If you are in your home, office, vacation home, boat, or car, the service should be available, and perform sufficiently similar to the service that is local.
A service that is available only, say, in Topeka, or in my living room would not satisfy this requirement.
Generally, we tend to think of clouds as being geographically dispersed rather than localized. However, upon further thought, it is clear that this is an implementation detail: We don’t really care or need to know whether Amazon.com has thousands of distribution facilities including a distribution facility just down the street from us or only one, say, in Antarctica, as long as an ordered book gets to us within a desired time frame, say, one day. Similarly, we don’t need to know anything about the physical locations for distributing ebooks as long as they arrive within an acceptable time frame, say one minute.
In the same way, we don’t really care or need to know whether Amazon Web Services has a data center just down the street from us or only one, say, in Antarctica, as long as the compute or storage task is performed successfully within an envelope of acceptable response time. We don’t need to know anything about Microsoft’s Hotmail servers or Salesforce.com’s data centers or Google’s search query servers or Google Apps’ servers. ...