Dave McCrory‘s Cloud Gravity series (Data Gravity & Escape Velocity) brings up some really interesting concepts and has lead to some spirited airplane discussions while Dell shuttled us to an end of year strategy meeting. Note: whoever was on American 34 seats 22A/C – we apologize if we were too geek-rowdy for you.
Dave’s Cloud Gravity is the latest unfolding of how clouds are evolving as application architectures before more platform capable. I’ve explored these concepts in previous posts (Storage Banana, PaaS vs IaaS, CAP Chasm) to show how cloud applications are using services differently than traditional applications.
Dave’s Escape Velocity post got me thinking about how cleanly Data Gravity fits with cloud architecture change and CAP theorem.
My first sketch shows how traditional applications are tightly coupled with the data they manipulate. For example, most apps work directly on files or a database direct connection. These apps rely on very consistent and available data access. They are effectively in direct contact with their data much like a building resting on it’s foundation. That works great until your building is too small (or too large). In that case, you’re looking a substantial time delay before you can expand your capcity.
Cloud applications have broken into orbit around their data. They still have close proximity to the data but they do their work via more generic network connections. These connections add some latency, but allow much more flexible and dynamic applications. Working within the orbit analogy, it’s much much easier realign assets in orbit (cloud servers) to help do work than to move buildings around on the surface.
In the cloud application orbital analogy, components of applications may be located in close proximity if they need fast access to the data. Other components may be located farther away depending on resource availability, price or security. The larger (or more valuable) the data, the more likely it will pull applications into tight orbits.
My second sketch extends to analogy to show that our cloud universe is not simply point apps and data sources. There truly a universe of data on the internet with hugh sources (Facebook, Twitter, New York Stock Exchange, my blog, etc) creating gravitational pull that brings other data into orbit around them. Once again, applications can work effectively on data at stellar distances but benefit from proximity (“location does not matter, but proximity does”).
Looking at data gravity in this light leads me to expect a data race where clouds (PaaS and SaaS) seek to capture as much data as possible.