Don’t get burned licensing Oracle software in Kubernetes!
Oracle describes their License Management Services (LMS) as being “designed to help customers ensure they are making the most of their Oracle investments in an effective and compliant manner”.
I suspect that many who have been unfortunate enough to have had first-hand experience with an Oracle LMS audit would not describe LMS nearly as charitably. You really don’t want to leave your Oracle license posture to chance!
Oracle’s contractual and license terms are often ambiguous. It isn’t uncommon that they are written in such a way that costs increase for innocuous management activities, or minor configuration mistakes that have no reasonable correlation to an increased amount of benefit that customers would receive from running the Oracle software. Oracle’s position with respect to licensing workloads running on Kubernetes continues their long-standing tradition of licensing-related non-excellence! For example:
- The Pod’s cpu limit is irrelevant — you must license the entire worker Node, not the Pod, even if only a small fraction of the worker Node is running Oracle software.
- If the worker Node is a VM, then Oracle’s partitioning policy applies and depending on the specific technologies involved you may need to license the entire underlying physical server, not just the worker Node VM. In fact, Oracle doesn’t stop there in their attempts to maximize their revenue — with certain technologies, they may demand that you license all of the servers in your cluster or even that you license ALL of the servers in ALL of the clusters that are managed by the same management platform, and I’ve personally seen Oracle insist that all servers in ALL clusters no matter how they are managed be licensed, even if only 1 server in 1 cluster can ever host the worker Node.
- For Azure and AWS, Oracle’s Processor Core Factor Table doesn’t apply, and therefore you require 2x† as many licenses as you would if you had provisioned a physical server with the same number of cores (although, at least in Azure and AWS, Oracle doesn’t force you to license the entire underlying physical server…).
- Of course, running your software on Oracle Cloud is not similarly penalized. Each processor license maps to 2 OCPUs, each of which correspond to a physical core. This would appear to be nothing more than an attempt by Oracle to increase their revenue by leading clients to use Oracle Cloud or devalue their licensing by half or avoid running their workloads in cloud. In 2 out of 3 of these options Oracle wins, but in all options the customer loses (either in terms of licensing costs or cloud provider choice/flexibility).
- Whether a container with Oracle software is actually running on a worker Node or not, Oracle takes the position that if an image has been ever been pulled to the worker Node, then licensing is required. You may need to license all of the worker Nodes that your Pod has ever been scheduled on. Even if you are just building an image FROM an Oracle image, you would need to license the build host… since builds pull images.
- Remember that some “Named User Plus” licenses have a minimum number of Named Users required per processor. Even if you only have 1 actual user, you might need to have many, many more Named User Plus licenses.
- All the other Oracle licensing complexities still apply (processor core factor, different definitions for processor depending on enterprise vs. standard, etc., etc.)
† For example, a Pod with a cpu limit of 0.5 running on a four-core worker Node with a Xeon Platinum 8256 4C 105W 3.8GHz Processor (which has a core-factor of 0.5) would require 2 licenses for WebLogic Enterprise Edition when licensing by processor. The same Pod running on an AWS r6i.2xlarge EC2 instance worker Node requires 4 processor licenses whether or not hyper threading is enabled (8 vCPUs = 4 cores) or not (4 vCPUs = 4 cores).
Oracle’s recommendation is that you accommodate these restrictions by labelling your worker Nodes and applying nodeSelectors (or nodeAffinity) to your Pods such that you limit the worker Nodes that images with Oracle software can be pulled to. This is inconvenient at best, and more realistically a major audit-trap. When a customer gets more value from software, it is reasonable to pay more to the vendor — but none of the above points fit that criteria.
Oracle’s licensing policies are, by far, the most onerous in comparison to any of the other major vendors that I have dealt with. With Kubernetes/containers (sadly for the customer), things aren’t any better. In general, I strive to simply avoid running Oracle software on Kubernetes entirely. Your situation may not allow you to take a similar position… and if so, all I can do is warn you to be extremely careful!
You can find all of the details on Oracle’s website:
Running and Licensing Oracle Programs in Containers and Kubernetes
Licensing Oracle Software in the Cloud Computing Environment
