Data gravity won’t stop the move to multi-cloud – here’s why

Overcoming data gravity is as simple as adopting a cloud-attached storage solution that connects to multiple clouds simultaneously.
11 March 2021 | 11 Shares
  • There are two challenges to solving data gravity – latency and scale
  • Businesses will have to adopt hybrid cloud strategies to address the challenge of data gravity
  • Adopting one or more clouds might make sense for business needs, but organizations must question if it makes sense for their data?

When working with growing datasets, moving the data around to various applications becomes cumbersome and expensive. Such a process is known as data gravity and it can lock you into an on-premises data center or a single cloud provider. In short, data gravity hinders a business’s ability to be nimble or innovative, and overcoming it is as simple as adopting a cloud-attached storage solution that connects to multi-cloud simultaneously.

Multi-cloud is well on its way to becoming a huge trend in enterprise organizations. One of the key benefits of a robust multi-cloud strategy was to leverage the unique innovations and functionalities that different clouds can offer an organization. However, as the main cloud service providers matured, the concepts of data gravity and vendor lock-in have inhibited the adoption of a multi-cloud environment.

In the coming years, datasets are only going to continue to grow and that exponentially at that, especially as organizations depend increasingly on artificial intelligence (AI) and machine learning applications. According to IDC, worldwide data creation will grow to an enormous 163 zettabytes by 2025. That’s ten times the amount of data produced in 2017.

How does data gravity influence a multi-cloud strategy?

The more massive the total amount of data stored in one place, the more applications, services, and other data are pulled towards it — and that is data gravity. As data grows, it becomes increasingly difficult and costly to move and the network of connections between data, applications, and other services becomes more complex. 

There are two challenges to solving data gravity; latency and scale. The speed of light is a hard limit on how quickly data can be transferred between sites, so placing data as close to your cloud applications and services as possible will reduce latency. As your data increases in size, it becomes more difficult to move it around. 

One way to reducing latency is by putting all of your data in a single cloud. Like the proverbial warning about putting all of your eggs in one basket, this approach has some drawbacks. Of course, the idea that a single public cloud will solve all of your problems is a pipedream that no organization can really make work although it may sound easier, in theory, to work with only one vendor. But with only one bill to pay and the same underlying infrastructure for all of your applications, it isn’t practical.

In short, between the demand for edge computing, the need to comply with data sovereignty regulations and the general need to be nimble and flexible, one cloud for all of your data is just not practical for a business to compete in today’s market.

That being said, with a hybrid cloud infrastructure, organizations can spread out apps and services to where their data is, to be closer to where they need it, addressing any latency problems and data sovereignty requirements. The key to making this work is to use a common operating environment across these various clouds and data center locations. If your organization is maintaining applications for many different operating environments, the associated complexity and costs may kill you competitively.

Pundits reckon organizations use a mix of Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, VMware, on-premises, and more — but there needs to be a way to make the apps and services portable between them. With a common operating system, you can write applications once, run them where it makes sense, and manage your whole environment from one console.