A little while ago after a question from a customer about supporting Oracle products on the Google Cloud Platform (GCP) I decided to take a look for any updates to the Oracle public cloud support policies. The document can be easily found on the Oracle website. I quickly noticed some significant changes in the new version of the document. More specifically, I’m referring to the changes that came with the latest version of that document dated January 23, 2017.
In this blog I will attempt to summarize the findings and my thoughts about the matter. Before proceeding any further, let’s begin with a safe harbor notice (as Oracle does) and mention that I do not work for Oracle and I am not a licensing expert. Some of my observations may be incorrect and everyone reading this post is strongly encouraged to make a fully informed decision only after consultation with an Oracle sales representative. After reading the Oracle licensing policy, you should bear in mind that the document provides only guidelines and it is published for “education purposes only”.
So, what do we have in the new edition? The document shares details about the Oracle licensing policy on public cloud environments including AWS EC2, AWS RDS and Microsoft Azure platforms. Alas, still no mention of Google Cloud Platform (GCP). It leaves GCP out of charted territory and even though it doesn’t explicitly prohibit you from moving your Oracle products to GCP, it makes it difficult to estimate the impact and cost.
The first paragraph has a link to listing of all Oracle products where the policy applies. Notably, the document explicitly lists almost all Oracle Database Enterprise Edition options and packs except Oracle RAC and Multitenant. If the absence of Oracle RAC may have some technical justifications, then the exclusion of the Multitenant option doesn’t make too much sense for me.
The next paragraph reveals a lot of changes. The new version of the document officially recognizes AWS vCPU as a thread, not as a core. Prior to January 23 2017, we used to have an AWS published document showing vCores by instance type for licensing calculations, and it was widely-used even though it was never officially provided by Oracle. People used number of cores from the document and applied the Oracle multi-core factor table on top of the cores count. There was never a similar document for Azure consequently considered a vCPU as a vCore and the same calculation using the multi-core factor table. The new version of the Oracle document now states explicitly that the two vCPU on AWS have the same licensing cost as one vCPU on Azure.
It’s explicitly stated in the document that either two vCPU from AWS or one vCPU from Azure are equivalent to one Oracle CPU license. Another statement confirms that from now on, the Oracle multi-core factor no longer applies for the mentioned public cloud environments. This can be a serious impact to people migrating or planning to migrate to AWS or Azure using Bring Your Own License (BYOL) policy. They may now find themselves in a difficult position. Either you plan your migration to a smaller environment or increase your licensing cost. In this case, it’s important to keep in mind that the size of AWS EC2 instance may have direct impact not only to CPU power but to maximum available I/O on the storage layer.
Additionally, there is now a section containing formally defined rules for Oracle Database Standard Edition and Standard Edition 2. According to the paper, we count every four vCPUs on AWS or two vCPUs on Azure as one socket. This means that you cannot have more than 8 AWS vCPUs for a Standard Edition 2 (SE2) license. Standard Edition (SE) allows you to have a 16 vCPU machine, and hence still provides more opportunities when sizing EC2 or RDS . Unfortunately, the SE is only available up to version 184.108.40.206 and support for that release is coming to an end. So what can still be used for an Oracle SE2 on AWS? We can get one of the *.2xlarge instances on EC2 or pick up a similarly sized RDS instance. Is that going to be big enough? That depends on your workload profile, but again, keep in mind IO limitations per instance type. It is going to be a maximum of 8000 IOPS per the instance. Not a small number, but you will need to measure and identify your IO requirements before going to the cloud.
On one hand, the new policies are way more clear and direct than they used to be and I believe that the clarification is good. It is always easier to plan your implementations and budget when you are confident of what to expect. On the other hand, it looks like we have to pay twice as much in licensing fees when moving to AWS or Azure when compared with any bare metal or OVM environment on premises. Will it make Oracle products more attractive for customers? I have some doubts that it will. Will it make the Oracle Cloud a more interesting target platform for cloud migrations? Possibly. That is likely the main goal of Oracle but we’ve yet to see if it works out for them as expected. I liked it when Oracle made Oracle Express Edition (XE) available for everyone for free and when Oracle Standard Edition came with the RAC option at no additional costs. While I don’t have any official numbers, I think that the Express Edition and RAC included with SE turned many customers onto Oracle products. However, I’m afraid that the new licensing policy for cloud may do the opposite and turn some people away from Oracle and consequently play out really badly for Oracle in the long term.
Interested in working with Gleb? Schedule a tech call.