Cloud Economics 4: Does Location Matter?
If you’ve been following the recent blogs, you’ll know the “L” in Joe Weinman’s C L O U D definition stands for location independence. One of the five distinctive attributes of cloud computing, location independence means that you can access your data anywhere. Location doesn’t matter in cloud economics.
Or does it? Like many things in life, there is a trade-off. Time is related to distance, even in cloud computing. The farther you are from your data source, the longer it takes for the data to reach you. And since timeliness has value, a better location should give better value. So maybe location does matter after all. The question is, how much?
Let’s put things into perspective by translating distance into time. The calculated speed of data flowing through a fiber optic cable is about 125 miles per millisecond (0.001 seconds). In real-world terms, since Chicago is located about 800 miles from New York City, it would take about 6.4 milliseconds for a “Hello world” message to traverse that distance.
As we discussed last week, for certain automated trading platforms that operate in the realm of microseconds (0.000001 seconds), 6.4 milliseconds is an eon of lost time. These systems can make or lose millions of dollars at the blink of an eye. For that reason you’ll find the serious players setting up shop right next door to their data center. The rest of us, on the other hand, can pretty much remain in our seats, even for real-time cloud applications.
Why? Well, first of all, the majority of industrial applications are already optimized for location. Most SCADA systems are implemented directly inside a plant, or as close as physically practical to the processes they monitor. Engineers who configure wide-area distributed systems are well aware of the location/time trade-offs involved, and take them into account in their designs. Furthermore, they keep their mission-critical data communication self-contained, not exposed to the corporate LAN, much less to potential latencies introduced by passing data through the cloud.
Of course, a properly configured hybrid cloud or cloud-enhanced SCADA can separate the potential latencies of the cloud system from the stringent requirements of the core system. What results is a separation between the deterministic response of the control system and the good-enough response time of the cloud system, which we have defined in a previous blog as “remote accessibility to data with local-like immediacy.”
Another area where the location question arises is for the Internet of Things. As we have seen, great value can be derived from connecting devices through the cloud. These of course can be located just about anywhere, and most of them can send data as quickly as required. For example, devices like temperature sensors, GPS transmitters, and RFID chips respond to environmental input that is normally several orders of magnitude slower than even a slow Internet connection. Latencies in the range of even a few hundred milliseconds make little difference to most users of this data. People don’t react much faster than that, anyway.
As we have already seen, user interactions with a cloud system have a time cushion of about 200 milliseconds (ms), the average human response time. How much of that gets consumed by the impact of location? Joe Weinmann tells us that the longest possible round trip message, going 1/2 way around the world and back, such as from New York to Singapore and back to New York, takes about 160 ms. Not bad. That seems to leave some breathing room. But Weinmann goes on to point out that real-world HTTP response times vary between countries, ranging from just under 200 ms to almost 2 seconds. And even within a single country, such as the USA, average latencies can reach a whole second for some locations.
However, a properly designed real-time cloud system still has a few important cards to play. Adhering to our core principles for data rates and latency we recall that a good real-time system does not require round-trip polling for data updates. A single subscribe request will tell the data source to publish the data whenever it changes. With the data being pushed to the cloud, no round trips are necessary. This elimination of the “response” cycle cuts the time in half. Furthermore, a data-centric infrastructure removes the intervening HTML, XML, SQL etc. translations, freeing the raw data to flow in its simplest form across the network.
What does this do to our Singapore-to-New York scenario? Does it now approach 80 ms? It’s quite possible. Such a system would have to be implemented and tested under real-world conditions, but there is good reason to believe that for many locations with modern infrastructures, data latency can be well under the magic 200 ms threshold. To the extent that this is true, location really does not matter.
