The basics of data storage can be related back to physics. Back in 2010, Dave McCrory (CTO, Basho Technologies, a distributed systems company) put forward the concept of "data gravity", McCrory said:
“Consider data as if it were a planet or other object with sufficient mass. As data accumulates (builds mass) there is a greater likelihood that additional Services and Applications will be attracted to this data…..Services and Applications can have their own gravity, but data is the most massive and dense, therefore it has the most gravity. Data if large enough can be virtually impossible to move.”
(For more on data gravity, see datagravity.org)
McCrory’s apt metaphor explains the challenges enterprises face in migrating and replicating stored data—and why they are reluctant to make changes to their existing storage, even if a new system could offer greater benefits. Data gravity can explain why enterprises are less likely to move storage to the cloud than other business workloads: 57% of IT decision-makers surveyed by Stratecast cite “data migration challenges” as the primary restraint to cloud storage.
Moving stored data takes a lot of effort, capacity, and bandwidth—and is almost sure to disrupt operations. As data volumes increase, the challenges exacerbate. Therefore, the place where data is created or initially stored tends to be where it remains.
In our last installment, we discussed how enterprise should prioritise deploying their core applications on a cloud platform. Enterprises should focus on resources oriented architectures and providing IT as a service, and not limiting their strategy and vision to certain products and technology. We discussed 3 types of implementation techniques for enterprise cloud:
· Creating a new cloud platform based on open sourced technologies like OpenStack;
· Host on external public cloud platforms such as AWS;
· Transform your existing IT infrastructure.
Which option should enterprises opt for?
The theory of data gravity answered this question: you shouldn’t choose platforms based on the pros and cons of their technical capabilities, but how much data you have accumulated in each platform.
Applications suitable for new architectures and external clouds are often:
1. Native to the cloud, user facing web applications;
2. Native legacy applications, but can draw more value by relying on web based data. This is the original concept of asteroids meet planets.
3. Native legacy applications, asteroids that hasn’t accumulated as much, whereby it’s still possible to move it to a new platform without much disruption.
Most enterprise core applications have accumulated years’ worth of data. It’s precisely these “data planets” that would struggle to move – or is impossible to move at all.
Does this mean your core systems is doomed to be stuck on whichever initial platforms you use for eternity? Would you never be able to reap the true benefits of newer platforms? Looking back, most IT companies started their journey in the 80s and 90s. In that era, most of the core systems were built on the now extinct dinosaur platforms. What allowed us to move from the stone ages of technology is because we constantly evolve onto newer platforms and develop new applications. These new applications quickly gained traction and collected mountains of data, which ultimately became the new core of your operations.
Relying on the same concept, I reiterate that platform revolution isn’t achieved through manual migration of your systems – but rather putting data and applications as your core, while developing new alternatives to replace your older core applications.
The best option for adopting cloud with regards to your core applications, isn’t to migrate the entire system, but rather to keep your data as it is, while modernizing your legacy infrastructure.
This conclusion may come as a surprise for many executives, but it makes perfect sense for IT managers and decision makers - because it's a realistic path, with low-risk and high-yield.
Today's enterprise IT architecture holds more value than most people expect, and is perfectly capable of achieving cloud like capabilities. So how can we achieve it? Stay tuned for our next installment.