This post will address an ongoing licensing myth that has just enough complexity around it, that it really trips up customers and account teams alike. As part of this post we’ll reference my vCPU licensing post, which I’d hoped would help answer this challenge, but for some reason, we still have folks confounded by Oracle sales people who, as sales will do, try to create friction that may cause people to hesitate from doing what they want with their workloads vs. doing what the Oracle sales people want them to do.
Constrained vCPU machines, as I’ve stated in the past, are in my opinion, mis-named, as it appears that someone could have access to more vCPU than what is available, (which the answer is NO, they don’t have access to anything other than what is listed and that was the purpose of my previous blog post demonstrated.)
Myths vs Reality
There shouldn’t be an issue here, but we should accept naming the offering “Constrained vCPU” will continue to drive this debate and challenge for customers. If you’re curious where this myth or confusion is coming from, please see the following Oracle documentation for licensing in a third-party cloud for reference as we go forward into the discussion.
To close the debate about COULD Oracle SOMEHOW license the customer for more vCPU than what is available on a constrained vCPU VM, the key is in the documentation from Oracle in which they used the term available instead of the term allocated. We should always focus on the licensing documentation and not what “someone said” or “sales claimed” or anything else verbally stated.
Contracts are Contracts
The only vCPUs that are available on the constrained VM skus are the ones which are active. vCPUs that are inactive on a constrained VM are not available in any sense of the word. The vCPU may have been allocated to the virtual machine, but they are not available to the virtual machine, which is common for any virtual compute in a public cloud.
The wording by which Oracle sales might have achieved their licensing objective is customers are required to count the maximum available allocated vCPUs of an instance type, because the inactive vCPUs have only been allocated, but they are certainly not available in any way, shape, or form makes this a myth and shouldn’t be entertained. I doubt they’d win many customers choosing this avenue, as they’re already losing significant customers as can be seen in percentage of new relational database projects by platform.
We Said What We Said
For us Oracle SMEs for Azure, this avenue of addressing the constrained vCPU issue closes the discussion and makes it a moot point. In legal matters – and Oracle licensing is indeed a contract – we shouldn’t admit imprecise or incorrect verbiage to the conversation. There’s no reason for us to debate it.
When any account team or customer is faced with this myth or misunderstanding by the Oracle sales person, we should advise them of Oracle’s mistake and move on to migrating them to Azure. All contractual issues are not liable to the whims of the Oracle sales team, but the global License Management Services (LMS) organization and must rule upon this in writing. Engaging with LMS would result in them performing a similar assessment as I did in my referenced post in the beginning of this one and list the number of available vCPUs in writing to the customer that are liable for licensing, which are, the available vCPU on a constrained vCPU VM.
Licensing Specialists
If your customer is looking for a partner to assist them with a licensing assessment for Oracle, especially an overall one since their Oracle licensing contract is between the customer and Oracle and not between them and Microsoft, I can’t recommend the following partners enough:
Microsoft
