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.