Essbase 19c appeared on the Oracle Cloud Marketplace back in September 2019, but that initial release was only available on a “BYOL” (bring your own license) basis. That meant that only customers who already owned – or went out and bought – on premises licenses were able to comply with its license terms. The list price for a single processor on premises Essbase license being  USD138,000 – plus a cool USD30k and change for annual maintenance – this presented a barrier to entry for potential users accustomed to subscription or usage models for cloud systems. It was also a problem for medium sized consulting shops and people like me who had been in the habit of running the local installations permitted under previous license terms for educational purposes. I’m sure I was not alone in making this point frequently and vigorously to Oracle (aka harassing Product Management) and I’m glad to report that an additional Marketplace option has now appeared under which Essbase is licensed on the Universal Credits Model or “UCM”. This means that there are two competing pricing models for Essbase 19c on Oracle Cloud Infrastructure. So how do they pencil out?

Caveat Emptor

First, a disclaimer: I’m exploring this stuff for the first time on my own (corporate) account. It can be tricky to identify every chargeable component in a stack, or in some cases every situation in which a sometimes-free component might become chargeable. While I hope the below math is correct, you must do your own due diligence and, if relevant, talk to your own Oracle Sales Rep before making any decisions.

Choices, choices…

Generally speaking, there are two pricing models when using universal credits (“universal” meaning credits you can choose to spend on any product) in the Oracle Cloud stack – a “Monthly Flex” model, and the “Pay as You Go”  model. The fundamental difference is fairly self-explanatory but the benefit of a monthly commitment is that it also entitles you to access the most preferential prices. Generally speaking, “Pay as You Go” carries a 50% premium over the “Monthly Flex” pricing. For regular production systems with predictable usage levels, “Monthly Flex” is going to make more sense, but if you’re running a personal account for educational purposes bear in mind that you will always be paying higher prices.

Assembling the Pieces

So what are you actually going to need to pay for running Essbase 19c on OCI? There will likely be some amount of the following types of service:

• Essbase License
• Compute – virtual machine ‘power’ (processor and memory)
• Block storage – this storage is effectively ‘disk’ that is used by plugging in to a virtual machine. For Essbase, it will contain the operating system, Essbase software and cube data storage
• Object storage – this storage type contains items that can be accessed without needing to be plugged in to a virtual machine (e.g. via API)
• Database – just like on premises systems, Essbase 19c requires a relational repository. The Marketplace instantiation procedure can create an Oracle Autonomous Transaction Processing database for you, or you can use an existing Autonomous or DBaaS instance
• Security – although the Marketplace instantiation procedure gives the option to use ‘native’ security this is probably not best for a production system. Oracle’s security provider is Identity Cloud Service (IDCS). In “Foundation” version IDCS is free; for “Standard” version pricing is per user per month
• Networking – networking costs will depend on bandwidth consumption and other setup considerations, such as whether a bastion host is used

For a production instance, I think it’s likely that the storage, networking and other ‘peripheral’ costs are likely to be much smaller than Essbase License and Compute (not to mention, they will be the same no matter how you choose to buy Essbase 19c). Database is arguably on the cusp by this criterion; the Marketplace instantiation process offers the helpful option of creating a relatively expensive Autonomous Transaction Processing instance, but if you’re willing to handle creating and managing the database yourself, Database as a Service can be much cheaper. At around USD2.50 per hour, ATP database costs might be a significant proportion for a small sandbox environment and using DBaaS (around USD0.40 per hour) saves a useful proportion.

Do the Math(s)

All those caveats aside, let’s estimate the list price cost of a decently sized (VM.Standard2.8, which means 8 OCPU and 120GB RAM) Essbase server with 2TB of block storage running 24/365 under the different licensing / commitment regimes. The input rates are as follows (all values in USD):

• Essbase BYOL per processor (converts to 2 OCPUs) – 138,000
• Essbase BYOL annual maintenance per processor – 30,360
• Essbase UCM Monthly Flex license per OCPU hour – 1.6411
• Essbase UCM PAYG license per OCPU hour – 2.4616
• VM.Standard2.8 Compute per hour – 0.5401
• Block Storage per GB per month – 0.0255
• Autonomous Transaction Processing Monthly Flex per hour – 1.6801
• Autonomous Transaction Processing PAYG per hour – 2.5202

I’m going to disregard networking, object storage, storage for the database instance, security and so on because I believe that they will in a typical environment, be much smaller than the above costs.

The results:

The Takeaways

What jumps out is that – assuming that OCPUs perform similarly to on premises processors – licensing via UCM with Monthly Flex looks like a pretty decent deal vs BYOL, given that there is no up-front license cost. Also that the ‘flexibility’ of PAYG carries a probably unjustifiable premium for a production-sized instance with associated availability.

A few of things to note about this simple methodology. First, if you were seriously considering buying on premises licenses (rather than being an existing customer using existing licensed capacity) to qualify for BYOL terms on an OCI installation, you would need to consider how to amortize that cost and also whether you actually paid list price for your licenses / maintenance (my experience is that sometimes purchase price is discounted but maintenance isn’t). Second, there is obviously a lot of potential to save on the UCM options if your system – or some environments in it – do not need to run 24/365. Third, as noted above, for a predictably used system there is really no reason to want to use the PAYG model. This is more applicable for development, education, evaluation, prototyping and so on.

One final thought that might be of interest to customers with existing on premises licenses. Named user licenses (list price USD2,900 per user) have not been much in favor in recent years. However, if you do own named user licenses, you are able to use 19c in the cloud on the same fundamental basis. That is, Oracle don’t care about your CPU or OCPU capacity, as long as you don’t exceed your user count. Dedicating one or two of your named users to an Essbase 19c system on OCI would be an extremely cost effective way of spinning up a very high-powered environment to investigate how well 19c on OCI handles your real-world workloads.