Data Gravity, Latency and the Hybrid
Cloud
Straddling the gap between on-premises and cloud service
providers (CSPs) is a highly relevant example of a common
architecture that presents data gravity and latency chal-
lenges. Nearly all large enterprises are now in various stages
of what could be described as hybrid cloud: At least some
use cases, workloads and data stores reside in CSPs, while
others remain on-premises or in private hosting centers.
Many enterprises see hybrid cloud as the optimal high-level
architecture, yet others have the goal of being operated
largely from within CSPs, realizing that fully transitioning
from on-premises to CSPs will take a substantial amount of
time.
This is an oversimplification, but it is useful to think of
hybrid cloud architectures as two high-speed networks (i.e.,
on-prem and CSP), with a lower-speed connection between
them. This simple description provides a context for us to
look at use cases that illustrate situations where hybrid
cloud might (or might not!) present challenges around data
gravity.
Use Case #1
Let us take the hypothetical but typical example of Com-
pany A, a financial firm that manages investments for their
retail customers. Like many large enterprises, Company A
has been conducting business for decades, with a large
on-prem collection of data stores upon which dozens of
company applications depend. At one point in time, all
applications were located on-premises as well. Thus, the
data and applications were all resident in the same high-
speed, on-prem network. However, consistent with a
recently announced cloud-first philosophy, it is assumed a
newly proposed end-user application, which needs to inter-
act with data on premises, will be hosted in the cloud (the
other high-speed network). So, where should the data for
this application reside?
One obvious position is that any data that must be accessed
or written by the application should be close to it. On the
other hand, because of the on-prem data stores that must
be accessed for this application, the application and the
on-prem data stores reside in two different locations sepa-
rated by a low-speed connection. We are facing a “rock and
56 | THE DOPPLER |
SPRING 2019
a hard place” situation: The application should be adjacent
to the data for latency and performance reasons, but the
application cannot be adjacent to the data due to data grav-
ity issues. Under the described circumstances, a solution
might be to create a data store in the CSP that is populated
with the necessary content, and then synchronize data back
and forth with the on-prem data store.
Use Case #2
Let’s look at a different example. Company B is facing
excessive storage costs and operational overhead in order
to maintain multiple copies of data (including offsite tape
storage) for disaster recovery (DR) purposes. Seeking to
take advantage of both the comparatively lower cost of
object storage in the cloud, and the simplicity of managing
backups without maintaining hardware, Company B has
decided to utilize a CSP as the destination for all offsite DR
backup.
Does this hybrid cloud pattern present any challenges at a
basic principle level? Do we care that the DR data is in the
cloud, while the application (backup software and associ-
ated operational management) resides on-premises? Unlike
Use Case #1, this is fairly straightforward. While one of our
previous principles states that low latency is better than
high latency, in this case, the latency between the two high-
speed networks simply is not relevant, because neither
storing nor retrieving data located in the cloud needs to be
performed on a moment-by-moment basis. Just as with
Company B’s previous architecture, the DR data need not
be part of the “center of gravity,” so CSP-based DR backups
work well.
Use Case #3
Company C is attempting to reduce its commercial RDBMS
footprint, which is currently based on Oracle RAC in their
on-prem data center. The intention is to migrate to cloud-na-
tive database services in order to reduce costs and simplify
operational management. However, as with most compa-
nies, the complexity of their on-prem database environ-
ments dictates that it is not possible or even desirable to
convert and move the entire database infrastructure all at
once. Thus, there is no option compatible with the overall
database migration business strategy, which avoids the
need to have database resources in two separate locations
for an extended period of time.