The Oracle Cloud Database Conundrum

What you should know: I am currently working for Orbit Cloud Solutions as Cloud Advisor, but any posts on this blog reflect my own views and opinions only.

Oracle has a long track record for providing first-in-class relational database management systems (RDBMS). For decades companies and public sector organizations have used them to store their most precious data and build their most critical applications on top of it. There is a good chance that your organization has some Oracle databases on its digital estate.

How do RDBMS fit into the cloud?

With the advent of the cloud, the push for other ways to create and manage databases became even stronger. Central to this is the CAP theorem, which states that of the properties of consistency, availability, and partition tolerance, only two can be of primary concern at any one time. While RDBMSs focus heavily on consistency and availability, cloud databases favor consistency and partition tolerance over availability. This is a significant shift in philosophy from large databases that scale vertically to lighter databases that scale horizontally. So we see that for new projects, a relational database is no longer the default choice for storing data which will sooner or later reduce the footprint of database engines such as Oracle RDBMS, Microsoft SQL Server, Postgres, MySQL or IBM DB2.

There will still be a need for RDBMS-style databases in the foreseeable future. However, another important point is that most applications that will be developed in the next few years will be focused on the cloud as a native environment. Fortunately, most popular RDBMSs are readily available in hyperscaler cloud environments. The most notable exception is the Oracle RDBMS.

So, what’s the issue with Oracle databases in the cloud?

Licensing limitations

Of course, you can install an Oracle database in AWS, Azure or GCP. But typically Oracle does not trust your hypervisor and requires that all underlying physical hardware CPUs be licensed.

For AWS and Azure, there are exceptions to this rule in Oracle’s licensing rules for cloud environments that allow Oracle databases and other products to be installed on virtual machines. There is a authorative list of database options and products that can be installed, with a notable exception being the Real Application Cluster (RAC) option that provides horizontal scalability.

The processor core factor

And there is another critical limitation: For authorized cloud environments AWS and Azure, the Oracle process core factor table does not apply. This leads to the general logic that two vCPUs with multi-threading enabled require 1 Oracle processor license.

Now Oracle has its own second-generation cloud offering called Oracle Cloud Infrastructure (OCI) that you can, of course, run databases on. The interesting thing here now is that in OCI, virtual machines are sized based on OCPU (Oracle CPU) that are roughly equal in performance to 2 vCPU in other cloud environments. But you only need 1 Oracle processor license for 2 OCPUs. So let’s do the math:

• AWS & Azure: 1 Processor license = 2 vCPU
• OCI: 1 Processor license = 2 OCPU = 4 vCPU

Installing a database in AWS or Azure will need double the number of licenses as it does in Oracle’s own cloud.

Push for Oracle Cloud Infrastructure (OCI)

So Oracle is clearly incentivizing the use of OCI to run its flagship database. OCI is a solid cloud environment, but it also has some drawbacks:

• Oracle has been a latecomer to the cloud party. Many companies have already chosen their primary cloud provider and made significant investments in upgrading their technology and capabilities.
• And that leads to the next problem: There are not many experts in the market focused on OCI. It’s hard to find experts who know AWS, Azure or GCP, but it’s almost impossible to find someone with a solid background in OCI. So it’s up to the organization to train their own staff. This is a chicken-and-egg problem: Oracle offers free training (and certification), probably to reach a larger developer community. Yet there are very few third-party books on OCI or training, indicating low market demand.
• The portfolio of services available in OCI is smaller than that of hyperscale cloud providers. Most of the essentials are there, but some specific requirements may not be covered at this time. The question here is whether Oracle is willing to invest the necessary resources to close the gap with AWS or Azure, which offer a similarly broad range of services.
• After all, there is far too often bad blood from previous experiences with Oracle’s business practices.

What does this mean for the cloud journey of organizations having a substantial Oracle footprint?

The licensing restrictions lead to typical scenarios for the use of Oracle databases in cloud environments:

• Hybrid Cloud: keeping the databases on-premises and moving the applications to the public cloud. This is often frowned upon primarily because of latency between the database and applications. And in terms of elasticity and flexibility, this is certainly not a very cloud-like experience.
• Public cloud: deploy databases on VMs or bare metal instances. This leads to an architecture that resembles an on-premises configuration, but does not provide access to technologies like Autonomous Database or RAC.
• Oracle Cloud: Run databases and applications in OCI. I have already discussed why this is not a solution that every organization might want to adopt.

The first two scenarios do not put the enterprise on what I would call a cloud-native architecture path. Customers are forced to use limited environments or stay on-premises. Workarounds to comply with licensing requirements drive architectural decisions, which in most cases leads to a suboptimal outcome for the business. Ultimately, this slows innovation and adoption of the public cloud, hurting the future of the enterprise.

So with Oracle databases in the cloud, it was “use the Oracle cloud or get left behind” most of the time.

Isn’t there a way around these issues?

For some use cases, however, a solution has been available for several years: Oracle and Microsoft have developed tools and integrations for an interconnect between Azure and OCI; details can be found in several of my previous posts. The interconnect improves a multi-cloud setup for running most workloads in Azure while moving databases to OCI. This works well, but requires knowledge and investment in OCI, which makes it less attractive.

Just recently, Oracle and Microsoft announced “Oracle Database Service for Azure” (ODSA), which I would consider an enhanced connection 2.0. Essentially, this provides a PaaS-like experience for using Oracle databases — including Autonomous Database or the Exadata platform — in Azure, with the bulk of OCI hidden from users.

This could be the solution for organizations that have chosen Azure as their primary cloud provider but still heavily rely on Oracle database technology, for example, if they currently run Exadata machines on-premises. I already took a brief look at ODSA in a previous post and found it very promising. So you should keep this in the back of your head when planning your next cloud migrations.