Relational Database Services – Not Quite as Simple as They Seem

by | Feb 1, 2018 | Cloud Optimization | 0 comments

Of all of the various ways in which companies can leverage cloud computing, establishing a cloud-based relational database would seem to be among the most straightforward. While companies may choose to set up their own database servers in the cloud, they can alternatively just purchase a relational database as a service, such as RDS offered by Amazon Web Services (AWS). What could be simpler?

Well, as you might guess, things aren’t quite as simple as they may first appear.

First the good news. Companies can realize many benefits from leveraging databases as a service. In the case of AWS’s offering, customers can select from six popular database engines including Oracle and Microsoft SQL Server. The database instances can be optimized for memory, performance, or I/O. Perhaps most valuable: AWS handles most administrative tasks, including hardware provisioning, database setup, patching, and data backup, freeing customers from these time-consuming and non-strategic tasks.

The downside to this approach? Broadly speaking, to get the benefits listed above, companies must relinquish some level of control and, often, visibility into the database configurations and operations. Some database offerings, including those from Microsoft’s Azure, are abstracted in a way that makes it quite difficult to know exactly what the database infrastructure includes, even the number of CPUs provided.

The RDS offering from AWS is more transparent in this regard, but has another issue. The size of available RDS instances varies by database types and regions throughout the AWS landscape. Companies may find that the best RDS match for their database needs is in a geography far removed from their cloud-based applications, raising potential latency and performance issues.

To help companies navigate the AWS RDS terrain, predictive analytics and cloud-optimization vendor Densify is modeling the global range of database offerings to create a multidimensional catalog that captures their types, sizes, and locations.

By using the Densify catalog, customers can automatically determine if AWS offers RDS instances that match their core requirements, including their relative proximity to the applications using the database. If chatty apps are forced to have several network hops to reach the database, performance can quickly degrade.

Of course, for Densify’s multidimensional catalog of RDS instances to have much value, customers must first have a good understanding of their fundamental database requirements and operations. With its analytics and optimization services, Densify actually learns the operational patterns of these systems and will automatically determine the optimal resource requirements to support their workload and service-level demands.

Once those core requirements are known, companies can use Densify to determine the optimal RDS locations and catalog sizes. In some cases, the database’s proximity to its client applications may have negligible impact on performance, permitting companies to shop for the most cost-effective RDS instances available, regardless of their location. In other scenarios, companies may need to favor database location over optimal database size and cost in order to achieve the most-balanced and efficient RDS solutions.