Oracle Integration Cloud pricing explained – OCI vs Classic

Last week at AMIS we had the task of estimating costs of a proposed iPaaS solution for one of our customers that runs on a fully managed cloud. As AMIS is mainly an Oracle partner we looked at how competitive we could make the pricing of the solution using Oracle Cloud compared to other vendors. In this blog I will not go into much details of this vendor compare matrix, as I want to focus on the pricing of Oracle and how it has changed over time. Bottom-line: for our use-case I was positively surprised by the outcome.

Let’s start by looking at the pricing of Oracle Integration Cloud (OIC), the licencing options and estimation rules belonging to each options. Currently the pricing page lists two main service types; Oracle Integration and Integration Classic. The difference between the two is that classic uses the OCPU metric, whereas the updated pricing uses a messages/hour metric. Both options are still available for you to purchase. For each service type you can choose between standard and enterprise package and two payments methods, pay-as-you-go and monthly flex. Optionally you can bring your own (existing on-premises) licence to get some mayor price cuts. In the next paragraphs I will go over the differences in more details.

OCPU metric (classic) vs Message pack metric

When you provision an Oracle Integration Cloud (OIC) instance you can choose between Integration and Integration Classic. The classic instance of OIC uses the OCPU metric, whereas the updated pricing model uses a messages/hour metric.

OCPU metric

The OCPU metric means you pay a certain amount per hour based on the amount of OCPU’s it uses. One (1) OCPU stand for a virtual machine with 8GB of memory and 120GB of (temporary) storage running on a Xeon general-purpose (E5) processor. It depends how beefy your instance will become how many OCPUs you need.

Messages/hour metric

This message pack metric means you pay a certain amount per hour based on the amount of message packs your environment needs to process all requests. The interesting, but also little bit difficult thing about this is, is how messages are measured.

A message pack includes a maximum of either 5000 messages (cloud license) or 20000 messages (bring-your-own licence) per hour. The unit of one message is a payload size of 50kb of in-and-out transmission from/to the Oracle Cloud Service. If a transmitted message is 270kb it will be counted as 6 messages, as it is rounded up. If you use process automation or visual builder you also need to calculate the amount of concurrent users. Process automation counts one concurrent user as 400 messages and Visual Builder counts one concurrent user as 100 messages.

So what happens when I exceed the amount of messages in one hour?

When making a good cost estimation the most important question is to know what happens when you exceed the amount of messages per hour. Do I immediately pay a second message pack for that single hour? Or am I charged for a second pack every hour after exceeding the limit? The answer is very clear.

You are charged for 5000 messages per hour, even if you don’t use them all. If your hourly average measured message packs over the day is exceeding 1.3 times the hourly message packs you are charged for a second message pack the whole day.

Limit: 5000 * 1.3 = 6500, 6500 * 24 = 156000 messages/day = 7.8GB of data.

Let’s break this down in a hour-by-hour example:

Timeframe	Messages/hour	Packs	Reason
00:00 – 09:00	0 messages	9	1 message pack for 9 hours (idle instance)
09:00 – 10:00	4500 messages	1	1 message pack for 1 hour
10:00 – 11:00	8000 messages	2	2 message packs for 1 hour
11:00 – 12:00	12000 messages	3	3 message packs for 1 hour
12:00 – 18:00	6000 messages	12	2 message packs for 6 hours
18:00 – 23:59	4000 messages	6	1 message pack for 6 hours
00:00 – 23:59		AVG = 2	33 packs / 24 = 1.375 (> 1.3) = 2 packs

This is recalculated every day. So if on a single day you exceed the limit, you only pay for the extra message pack that day.

Choosing for OCPU (classic) or Message packs

If you are looking to purchase a new instance of Oracle Integration then Oracle recommends to go for the new pricing model and service offering. The reason is that Oracle stopped managing the classic environments and made backup/restore not supported anymore.

So for (new) customers that want a fully managed cloud environment like our customer, you need to estimate costs using the message pack metric. Therefore, I will ignore the old classic pricing from now on.   

Choosing between standard or enterprise

Oracle Integration Cloud comes in two flavours; standard and enterprise. The difference is, as you may expect, the amount of features / components available. Let’s look at the differences in table below:

Version	Features
Standard	Integration, including: • SaaS Integration Adapters • Technology Adapters (FTP, File, DB, AQ, JMS) • Scheduled File Transfer Visual Builder, including: • Business Object Modeler
Enterprise	Integration, including: • Same as Standard + On premise Application Adapters Process, including: • Process Automation Visual Builder, including: • Same as Standard

Looking at this list, enterprise is interesting if you need BPM / process automation like features, you want to connect to on-premises application adapters like Oracle EBS, JD Edwards, Siebel or SAP or you want to host an Integration Cloud instance on-premises.

Choosing between `Pay As You Go` or monthly flex

When estimating the monthly price you need to choose between the payment method that fits you or your customer the best. In this case `Pay As You Go` means no strings attached and you can create and destroy instances at any point in time on your cloud subscription. This pricing model, based on hourly estimation, is more expensive then monthly flex. Monthly flex means you pay upfront and get discounted for the commitment you make.

Somethings you need to know about monthly flex:

• You can only purchase this option if you engage in a contract of at least one year
• The total amount of you purchases needs to be higher than 900€ (or 1000$)
• This means that only purchasing Integration Cloud does not reach this minimum as it only costs 539€ (or 600$) per month if you go for monthly flex.    

Below an example of a cost estimation of Oracle Integration Cloud standard with one 5000 message pack per hour (in €). Notice the Monthly flex option is not available to us. If you exceed the daily limit you pay around 52 euro that day instead of 26 euro (based on month of 31 days).

Bring your own license

Oracle also offers you to bring your own (existing) license. So for example if you have a existing fusion middleware license or a special deal with Oracle that allows you to bring in an own license. This will drastically change the hourly price rate with a 60% discount.

Price comparison with other vendors

In the beginning of the blog I mentioned I’m not going into detail of our iPaaS vendor compare matrix, but I want to give you some ballpark figures (all list prices), as they offer similar platforms:

iPaaS Vendor	Start price per month (€)
Oracle Integration Cloud – Standard	808,- (PAYG) / 539,- (1-year contract)
Oracle Integration Cloud – Enterprise	1617,- (PAYG) / 1078,- (1-year contract)
Dell Boomi Integration	Slighty more then OIC enterprise (1-year contract)
Informatica Intelligent Cloud	2400,- (unclear if PAYG or contract based)

Key conclusions

Looking at similar iPaaS solution the new Oracle Integration Cloud pricing model is very competitive with other vendors that offer similar platforms. Where other vendors charge you per connector (such as mulesoft) or don’t offer pay as you go, Oracle has chosen to charge you based on volume of message. Including a grace window of 29% before changing an extra message pack. So for small companies or volumes Oracle Integration Cloud a very interesting option.

But what about Azure Logic Apps?

My opinion is that Logic Apps is also interesting for small companies and simple enterprise integrations. Azure charges you based on step executions in a process and on the type of connectors, so it all depends on the complexity of you processes you develop. Based on functionality it is hard to compare Logic Apps as it is very basic and limited in use-cases. It misses functionality the other vendors offers, such as request tracing and instance monitoring, which you need to set-up separately in Azure.

I’m not dismissing Azure when advising an iPaaS platform, as in some cases it is the better option. For example, at another client we proposed to use Logic Apps, over Oracle Integration, even if the pricing was 30€ more expensive per month. In these cases the final choice for an iPaaS platform may just depend on if the client already has something running on that specific cloud verdor.