Navigating the Oracle Licensing Policy Update: A Look at the Facts

POSTED ON May 25th, 2017 in:
By clckwrk

If you’re like us, then you’re never far from the pulse when it comes to changes in Oracle software licensing. Keeping up to date with this is a safe way to be sure that you’re making the best decisions for your business when it comes to saving costs and operating cloud applications efficiently.
The change that we all seem to be struggling to digest is Oracle’s January 2017 update to its online policy document, “Licensing Oracle Software in the Cloud Computing Environment”. As you’ll probably know, the document outlines how to work out how many licenses you need to run Oracle products in different Cloud hosting environments. And, put simply, the update is to how users are charged for licenses on Oracle software in a non-Oracle environment.
This one affects companies running their Oracle systems using Cloud hosting solutions like AWS. So… lots of us. From the looks of things, the number of licenses needed to run software in the non-Oracle Cloud has been doubled with the new update. More licenses needed means more money spent. The IT world’s response? Well, uproar, it seems.
Always the rationalists, we like to remain a little more level headed. We were hesitant to jump quite so quickly onto the Oracle-bashing bandwagon, so we decided to break things down and look at the facts before getting upset. And, of course, we’re happy to share our insight. Let’s take a logical look at the changes to the Oracle licensing policy.
So, what’s actually different? 
The change is to the method used to work out how many licenses you’ll need. Here’s the relevant section from the previous policy document. Handy hint: it refers to Amazon Web Services – Amazon Elastic Compute Cloud (EC2), Amazon Relational Database Service (RDS) and Microsoft Azure Platform as the ‘Authorized Cloud Environments’.
“For the purposes of licensing Oracle programs in an Authorized Cloud Environment, customers are required to count each virtual core as equivalent to a physical core. This policy applies to all Oracle programs available on a processor metric. 


Licensing Oracle Database Enterprise Edition on a single instance of 8 virtual cores (on Intel multicore chips; see the processor metric definition on the price list), would require 8 * 0.5 = 4 processor licenses (each virtual core is considered equivalent to a physical core).”
You can see that the method includes the ‘core factor’ multiplier of 0.5 from Oracle’s Core Factor Table document. Here’s the latest version of the policy document:
“For the purposes of licensing Oracle programs in an Authorized Cloud Environment, customers are required to count as follows: 


Amazon EC2 and RDS – count two vCPUs as equivalent to one Oracle Processor license if hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper-threading is not enabled. 


When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.”

 

No more multiplier of 0.5. In the previous policy, each virtual core in AWS is equivalent to half a physical core. According to the updated policy, a user renting two AWS CPUS will now need to pay for two full licenses, as opposed to just the one.
 
Any evidence? 
Let’s use a specific example to do the maths. Here, we’ve calculated the cost of licensing Oracle RDBMS Enterprise Edition on a selection of different AWS instances (both hyper-threaded and non-hyper-threaded) using AWS server information.
Previous Policy 
With hyper-threading: 
For example, an r3.xlarge (2 virtual cores, 4 vCPU)
4 vCPU = 2 virtual cores = 2 physical cores * 0.5 = 1 license
For example, an m4.4xlarge (8 virtual cores, 16 vCPU)
16 vCPU = 8 virtual cores = 8 physical cores * 0.5 = 4 licenses
Without hyper-threading: 
For example, an m3.medium (1 virtual core, 1 vCPU)
1vCPU = 1 virtual core = 1 physical core * 0.5 = 1 licence
For example, a t2.xlarge (4 virtual cores, 4 vCPU)
4vCPU = 4 virtual cores = 4 physical cores * 0.5 =2 licenses
Updated Policy: 
With hyper-threading: 
For example, an r3.xlarge (2 virtual cores, 4 vCPU)
4 vCPU = 2 licenses
For example, an m4.4xlarge (8 virtual cores, 16 vCPU)
16 vCPU = 8 licenses
Without hyper-threading: 
For example, an m3.medium (1 virtual core, 1 vCPU)
1vCPU=1 licence
For example, a t2.xlarge (4 virtual cores, 4 vCPU)
4vCPU= 4 licences
To clear that up: 
Number of Licenses Required (Oracle EE)
Previous Policy Updated Policy
r3.xlarge 1 2
m4.4xlarge 4 8
m3.medium 1 1
t2.xlarge 2 4

 

You can see that the licensing requirement is double with the new policy, with the exception of a small non-hyper-threaded instance such as an m3.medium.
But…why the change? 
 
Well, we’re not short on opinions when it comes to this. One we’ve come across is this: the document now explicitly mentions how vCPUs are licensed on different Cloud providers, which it didn’t before. So, the terminology is clearer and more consistent with AWS. Good news –clearer is better as far as we’re concerned.
On the other side, most of the community sees the update as a way to push Oracle’s own Cloud hosting software. Back in 2015, Larry Ellison made the bold claim that the Oracle Cloud would be cheaper and faster than Amazon’s offering. Making it more expensive to use competitors like AWS, and Azure looks a lot like a way to tempt migrating customers towards the Oracle Cloud.
Is there another way to look at this? 
 
We think so, yes. Let’s look at this from the perspective of a business moving from on-premise to AWS. An AWS instance does, generally, give better performance than an equivalently sized on-premise server. Essentially, Oracle aligned the costs.
Any evidence? 
 
Again, let’s use a specific example to do the maths when it comes to performance. Using the TPC-C benchmark standards, we can see that an on-premise Dell PowerEdge T620 server with 20 cores / 40 threads has a performance figure of 112,890 tpm (see the webpage here). Running the TPC-C performance tests against an AWS m4.10xlarge with 20 cores / 40 vCPUs we can generate a performance peak of 233436 tpm. which is twice that of the similarly specified Dell T620*:
* the above comparison isn’t 100% scientific, but it does show the general performance advantage of the AWS instance.
Another way to look at performance is to compare the Geekbench multi-core benchmarks for a Dell PowerEdge T620 with 16 cores, 32 threads and a c3.4xlarge with 8 cores, 16 vCPUs:
Server Multi-core Score
Dell PowerEdge T620 28191
c3.4xlarge 23251

 

The c3.4xlarge will cost the same as the on-premise T620 and still has roughly equivalent performance.
So, yes, licensing costs have mostly doubled when it comes to running Oracle products in AWS. But you can also see that a company moving from on-premise could get similar performance from a smaller AWS instance with fewer vCPUs. Plus, if you’re clever about how you make use of AWS, you could take away the need for a standby database: more money saved.
Other thoughts? 

Yes, just one. The licensing policy document is intended for “educational purposes only”. It’s a guide, as opposed to a basis for your contractual agreement. Making the right move for your business means pushing for the best deal, and Oracle will need to acknowledge previous agreements reached ahead of the 23rd January 2017 policy update.
Thinking about migrating your systems and need more insight into Oracle licensing policy? We can help. Get in touch here
 
  • footer-client
  • footer-client
  • footer-client
  • footer-client
Web Design by Appnova