pageloader

In the non-virtual world, the words: “My place or yours…?” is often followed up with the word “regret”. This is mostly because the decision is made in an endorphin-rushed haze without understanding consequence.

Much the same happens when an on-premise customer considers to move their Oracle licenses to an IaaS Cloud Platform (Oracle’s or others) and they intelligently decide to bring their on-premise Oracle license with them (known as BYOL).

This is a fair consideration for the following reasons:

  1. Sweat the existing on-premise Oracle license investment.
  2. Be exempt from Oracle often disputed ratio conversion for going from on-premise to Cloud (Typically a 1: 3 conversions with no compensation for the license fee paid).
  3. Most customers already have an Azure Cloud subscription (because they are also a Microsoft customer) and it makes financial and/or logistical sense to have as few Cloud environments as possible.
    The obvious question is then: When choosing an IAAS Cloud Platform, an Oracle on-premise customer should take time to understand the impact if they want to BYOL.

Here’s why:

  1. You get less
    Let’s take an example where Customer A has 1 x Processor of Oracle Database Enterprise Edition license, currently on Oracle Support:

    Platform BYO Oracle License What is required for 1 Processor Notes Equivalent in Physical Cores
    AWS
    (EC2 & RDS)    		 1 x Processor of Database EE 2 x VCPU Hyperthreading enabled
    AWS
    (EC2 & RDS)    		 1 x Processor of Database EE 1 x VCPU Hyperthreading NOT enabled
    Azure 1 x Processor of Database EE 2 x VCPU Hyperthreading enabled
    Azure 1 x Processor of Database EE 2 x VCPU Hyperthreading NOT enabled
    Oracle
    (IaaS)    		 1 x Processor of Database EE 1 x VCPU 1 x OCPU = 4 vCPU = 2 {physical Cores
  2. Your ULA is worth less:
    The value (utility) of Oracle on ULA (Unlimited License Agreements) for programs licensed on the Processor and/or Named User Plus metric (Typically Oracle Database & Middleware programs) are fundamentally increased through maximising the Certification Value at the end of the ULA term. This effectively means that a customer needs to maximise the number of Processors that the Oracle ULA programs considered to be licensable to maximise the certification quantity of Processors.

    Most of Oracle’s ULA’s in recent times (last 5 years at least) include a provision in the Certification Clause whereby Processors in a 3 rd Party Public Cloud environment (e.g. AWS, Azure) cannot be counted for Certification purposes.

    This essentially leaves the customer with 2 problems:

    Problem 1: High probability of compliance breach on day 1 post ULA:
    Considering that the customer cannot certify the Oracle Processors in a 3rd party cloud, they would not have Oracle license coverage for those environments post ULA Certification. This means that they would either have to move out of the 3rd Party Public Cloud before the ULA expires or buy additional Oracle licenses to ensure license compliance is maintained.

    Problem 2: Low certification value erodes the investment value:
    The Oracle Support value associated with the ULA stays constant post certification, regardless of how many licenses the Oracle customer Certify. This means that a low level of Certification would result in a high average cost per Processor of the Oracle programs involved.

  3. Support restrictions:

    Depending on the 3rd Party Public Cloud providers’ platform, Oracle may not offer their full suite of Support Services. It is a function of the hardware, O/S, and version of the Oracle programs that will determine if full Oracle Support Services will be delivered.

  4. Increased license compliance risk

    The economics associated with most Public Cloud environments is anchored in volume and the quest to reduce the costs per processing unit. This means that all the hardware in the Cloud is virtualised to manage performance and redundancy whilst maintaining the lowest possible price point. It is well publicised that Oracle and Virtualisation platforms (other than their own OVM – and only under specified conditions) do not lend itself toward an easy conversation with Oracle’s License Auditors (LMS). Whilst many (including us) have successfully disputed Oracle’s position on this regard, it is important to understand that: The responsibility for license compliance rests exclusively with the Licensee and blaming the Cloud service provider is not a defence that Oracle accepts.