Oracle Database @ AWS – What it means for AWS customers

rc24-oracle-aws

What Was Announced, What Does It Mean?

Oracle made a major announcement in September at their annual Cloud World conference that they were bringing their Exadata service and Autonomous Database service to the AWS cloud. While technically this isn’t anything very new, we’ve already seen the same play with Azure and GCP recently, it’s a major development simply because of the scale of AWS. This brings the Oracle cloud database offerings to a vast multitude of AWS customers who previously could only access these with a multi-cloud strategy and all the associated multi-cloud operational challenges.

While doing Oracle databases in AWS has long been possible using the AWS EC2 or RDS services, these new offerings bring additional flexibility and ease to migration to organizations utilizing Oracle technology stacks. The chief benefit is not technical but rather in licensing and the agility that additional licensing options can bring to operating in the cloud. The immediate advantage noted by most observers is that using OCI infrastructure embedded in AWS can allow leveraging more customer-friendly database licensing metrics. In order to encourage adoption of OCI technologies Oracle has quite simply written their licensing rules to allow licenses to go further on OCI stacks vs other clouds. Without getting into all the complexities, the simplest way to think of it is that one processor license of an Oracle core technology product covers 2 vCPUs in AWS/Azure/GCP but covers 4 vCPUs in OCI offerings. The secondary and more subtle advantage of utilizing the Oracle Database @ AWS offerings is flexibility.

Think Elastically

To illustrate the importance of cloud flexibility and elasticity, let me relate an operational scenario I lived through.  I distinctly remember the first time, nearly a decade ago, when I realized that the elasticity and flexibility of cloud environments provided DBAs operational opportunities in a way that on-premises IT never could. At the time I was a DBA supporting a new release on a very scaled customer-facing web app in AWS.  I was part of the team responsible for the fleets of API servers and the database back ends. The release had gone badly, and the software was failing intermittently but the production support team and development team couldn’t figure out why. The issue wasn’t reproducible in lower environments, it needed a great degree of scale to manifest as it was some sort of subtle performance issue that would cause timeouts and user-facing errors. Because we couldn’t reproduce it, the developers were trying to diagnose the issue based on production servers but due to security and performance concerns the logging levels were limited in production. 

I recall the exact moment that an exasperated developer finally threw up his hands and suggested that we should revert the release because what they really needed to find the issue was a full prod-scale environment with heavy traffic and application servers in full debug mode. In the context of the moment, he was basically giving up on identifying and fixing the issue quickly because he just didn’t have the right environment in which to perform a detailed issue investigation. I started to sympathetically agree with him and then realized that his ask was not only possible, but possible quickly and easily. A few quick conversations later I had some extra cloud spend approved and was pointing our production deployment jobs at a test environment and bringing up hundreds of application servers. Simultaneously I was cloning dozens of open-source databases into the test environment and within 90 minutes I had a full-scale prod environment into which we could aim traffic generators and reproduce the issue. It was hot fixed in production that same day and the teams were praised for being able to quickly resolve a thorny production issue.

Overcoming Licensing Barriers for Greater Flexibility

The kind of flexibility that leads to audacious operational troubleshooting tactics like creating a temporary full clone of production has always endeared public cloud computing to me.  However, with commercially licensed software that required licensing per processor, it was never possible. The kind of scenario I just described doesn’t make sense if it causes an organization to risk being out of compliance with licensing or must procure additional costly perpetual licenses.  That’s always been the issue with doing Oracle database in any sort of public cloud environment, the need to still treat databases like on-premises servers with pre-planned capacity because of the cost and arduous process of negotiation license purchases with Oracle.  I’m hopeful that this latest announcement from Oracle and AWS means this is about to change.

This announcement from Oracle and AWS specifically mentions that the Oracle database services will be available on-demand and with a Bring-Your-Own-License (BYOL) or License-Included (LI) model in the AWS cloud.  From a licensing perspective this adds some very interesting options and flexibility for organizations utilizing Oracle Database in the AWS cloud.  Suddenly scenarios like cloning production environments for testing purposes start to become feasible.  This flexibility has never been available to Oracle database workloads, outside of customers with unlimited enterprise agreements, because the licensing restrictions. It was never possible to flex Oracle Database Enterprise Edition workloads to do interesting things like clone a database into a transient performance test environment or a reporting environment for a one-off purpose.  The cost of the compute and storage has always been negligible for these one-off time-limited purposes but the cost of procuring additional Oracle licenses was prohibitive to any sort of agile approach to cloud computing.  With the LI options for the Oracle offerings in AWS, suddenly these flexible operational scenarios become valid. 

In Conclusion

Overall, I couldn’t be more pleased with this announcement from Oracle and AWS. Additional options and flexibility are never a bad thing, and this increases the migration path options and operational flexibility available to organizations running an Oracle Database in the public cloud.  If your organization is wondering how these new technology options can improve flexibility or reduce Oracle spend in AWS, House of Brick would love to help you out. 

Table of Contents

Related Posts