On a cloud journey, few topics spark as much confusion and frustration as licensing Oracle databases in the cloud. I remember the first time I was faced with licensing dilemmas outside the Oracle Cloud Infrastructure(OCI) — my head spun with questions. Do I account for all vCPUs? How does hyperthreading affect my licensing requirements? Let’s dive into the murky waters of Oracle licensing and bring clarity to these convoluted challenges.
TL;DR: Oracle licensing outside of OCI presents significant challenges, including confusing vCPU licensing, potential discrepancies in cloud provider agreements, and the undeniable need for clearer communication from Oracle, AWS and Microsoft.
Understanding Oracle’s Licensing Options
Processor Licenses vs. Named User (NUP) Licenses
When it comes to Oracle’s licensing, there are two primary options: Processor licenses and Named User Plus (NUP) licenses. These serve different needs depending on how you plan to use Oracle’s software.
Processor licenses are typically used when the application is going to run on servers with multiple users. This licensing model counts the processors in your server. You need licenses for each processor. This can quickly become expensive in larger environments.
On the other hand, Named User licenses are designed for situations where there are fewer users. You can purchase a license for each user accessing the application. Sounds simple, right? But here’s the catch: You need to meet the minimum licensing requirement, often leading to confusion.
Initial Setup and Costs of Traditional On-Prem Licensing
Setting up Oracle’s software on-premises often involves significant initial investment. First of all, you need to purchase licenses according to your chosen licensing metric, e.g. Processor licenses for each Core you are running Oracle databases on. In most enterprise environments, you will license the Oracle Database Enterprise Edition and probably some additional database options to meet your requirements (e.g. security) and make life easier for DBAs and developers. These are one-time costs for the license and grant you the perpetual right to run the database with the purchased options. To get support from Oracle when problems pop up and to have access to future updates and upgrades, you will have to buy recurring support and maintenance, usually around 22% of original purchase value per annum.
This means that you need to do a good projection of the capacity needed in the future and purchase licenses accordingly. Which is very much different from what we expect from resources deployed to the cloud. In the cloud we want to have elastic environments which can be scaled with demand. The traditional Oracle licensing model simply does not support that.
How Licensing Terms Apply Differently in Various Cloud Setups
Bring-your-own-license (BYOL) means that you procure your licenses and then use these for your Oracle databases deployed to the cloud. So this one is very much like the traditional model discussed above. Then there is the pay-as-you-go (PAYG) model, which means that you only pay for the license when you actually use it – which is much more in line with the ideas of having elastic resources in the cloud.
If you’re using Oracle Cloud Infrastructure (OCI), you might find it easier to manage licenses and use both BYOL and PAYG. But what about other authorized cloud providers like AWS, Azure or Google Cloud? In these cases, the licensing model can become tricky.
In AWS, Azure and Google Cloud you can deploy IaaS (virtual machines or bare metal instances) and use your own licenses (BYOL). Only in AWS you get an elastic PaaS offering for running Oracle Standard Edition that is not coming directly from Oracle.
Lately, Oracle introduced their Oracle @ Hyperscaler offering, which provides you with access to PaaS running on OCI infrastructure colocated in AWS, Azure or Google Cloud datacenters. As this requires a pretty hefty minimum consumption, it is not working for many smaller enterprise setups. I probably will discuss the Oracle @ Hyperscaler offering in another post, but for this post I will focus on the options for running Oracle databases on IaaS.
So in numerous instances, you will deploy a virtual machine that runs the Oracle database and bring your own licenses.
How Cloud Environments Complicate Licensing Calculations
Remember that in traditional, on-premises setups, things are pretty straightforward. You either need a Processor license for the cores used or licenses for Named Users (NUPs). But in the cloud, it gets trickier. For non-OCI cloud environments Oracle introduced new rules. For instance, Oracle focuses on threads rather than vCPUs when it comes to counting Processor Licenses needed. Sounds simple, right? Not quite.
Oracle counts how many threads rather than how many virtual CPUs (vCPUs) are in use. If hyperthreading is enabled, you’d need a license for every two vCPUs.
- If hyperthreading is disabled, one vCPU equals one Processor License.
- However, if hyperthreading is enabled, you’ll need one Processor License for every two vCPUs.
So make sure to understand the type of virtual machine you are using for your database.
Oracle’s Unique Treatment of vCPUs in Non-OCI Environments
Let’s explore something even more mind-boggling. In the cloud, specifically non-OCI environments, Oracle doesn’t apply the core factor rules. This means that, unlike on-premises setups where one Processor license can cover two cores, in the cloud, you need one Processor license for every core with hyperthreading disabled. This will double your licensing fees.
Can you imagine planning a budget only to find out you need to spend twice as much for licenses? That’s a reality many face with Oracle licenses in authorized cloud environments. And that’s why many organizations try to get rid of their Oracle databases just to avoid those license games.
Debating the Constrained vCPUs Approach
Understanding the Strategy of Constrained vCPU VMs
Microsoft and AWS have a seemingly smart approach when it comes to work around the licensing requirements for virtual CPUs. Their constrained vCPU VMs aim to provide clients with cheaper options for running Oracle databases. The idea is pretty simple: you pay for more resources, but some of them are capped. For example, for Azure Standard_E16-8s_v3 VMs you will pay for a 16 vCPU VM, but only 8 vCPUs are usable. Microsoft argues this significantly lowers licensing costs since, in theory, you only need to license the functioning vCPUs.
In a blog post, Microsofts DBAKevlar describes in detail why she believes that Oracle needs to accept the constrained vCPU VM approach. It makes a lot of sense. The tools used to identify the cores used show only the lower number of vCPU. And you do not have to tell Oracle that you are running on a constrained vCPU VM. Everything looks right.
Oracle: No, I don’t think so
Unsurprisingly, Oracle doesn’t see it that way. They argue that the maximum available vCPUs—regardless of whether they’re actually utilized—must be licensed. So you need to license all 16 vCPUs.
But then I found another statement from a Microsoft employee about the OS licensing on constrained vCPU VMs: It seems you need to license 16 vCPUs for a Standard_E16-8s_v3 running Windows OS. How is this consistent? Are all 16 vCPU somehow available, or are 8 vCPU fully disabled? Is Microsoft opening a discussion about hard partitioning in their environment, even as an authorized cloud?
Overall, it is up to a license audit by Oracle for you to find out. Not a pleasant exercise.
The Need for Clear Communication and Guidelines
As a part of the tech community, I’ve seen feedback flooding in from users navigating this minefield. Some express relief at the lower operational costs, while others are utterly confused and worried about unexpectedly high licensing fees. Many experts recommend involving Oracle Licensing Management Services (LMS) for clarity, but who really wants to undergo that ordeal?
We must push for Oracle and AWS, Microsoft to clarify their licensing terms publicly. Licensing options for Oracle that work on-premises don’t translate well into the cloud for IaaS setups. When AWS, Microsoft and Oracle put their heads together and clarify, everyone wins. I believe a public-facing FAQ or dedicated statement might be helpful to demystify these complexities.
Clear, concise policies can make a world of difference for cloud adopters. Knowing exactly how many licenses we need saves time, money, and stress. No one wants to find out later that they need to fork over more cash because of unexpected licensing counts.
My Hopes for Future Clarity
Looking ahead, I am hopeful for better clarity in future licensing updates. Having clear guidelines from Oracle, AWS and Microsoft would enhance cloud adoption for applications relying on Oracle databases. Instead of navigating a murky system, we could focus on what truly matters: building great applications and providing value to our customers.
In short, the need for clear communication cannot be overstated. If Oracle, AWS and Microsoft prioritize transparency, we could all breathe a little easier. Who wouldn’t want that? Let’s advocate for clarity and ensure that users everywhere can benefit from straightforward licensing rules! In this evolving landscape, communication is key. I truly hope we’ll see more clarity soon.