Why OCI for EBS and not AWS

7th May 2022

One of our Customers had already invested heavily in AWS and So when the time came to move some Oracle workloads to public cloud they were loathe to take our recommendations for OCI and chose to soldier on with AWS. The argument they had was Oracle supports other public clouds.

Well unfortuntaley the customer is always right and we ended up in a situation where we had to support E-business suite on AWS. Now the fact is that Oracle explicitly states that they certify EBS on OCI , this means that they test everything on OCI and gurantee it will work. This is a big thing for a complex software like an ERP solution. On AWS at the most what you get is support on a best efforts basis. So if something goes wrong Oracle support will not have a similar AWS tenancy where they can troubleshoot for you , Unlike in the case of OCI where they most certainly will have . This can  cut a lot of time of  a support issue that would other wise go in figuring out environmental differences.

The next thing is its so easy to spin up EBS on OCI that when faced will having to do the same on another cloud without similar benefits only then does one appreciate the Non functional benefits of running EBS on OCI.

First off Oracle Linux has prevalidated RPMs that can be installed as a one touch mechanism to ensure that the system is tuned and ready for Ebusiness suite. On AWS with a OS like RHEL these are not applicable and the same has to be done manually and painstakingly  to ensure nothing has been missed.

Contrast that with the pain of downloading EBS installation files, Database and techstack update files, RUP and other patches and then applying them one by one to a new installation. We are talking about weeks of effort here to get a system that is similar to  a production system. 

Then if we want to talk about cloning and deployment in OCI we have the EBS cloud manager which is a great tool for cloning automation in OCI. of course as its OCI specific it won't work in other public or private clouds.  

OCI also has best practices for using shared FSS filesystem and they do certify use of the same with EBS where as in other clouds you are more on your own. Shared filesystems are an essential part of any large EBS deployment so again this is always going to be an issue that hangs like a sword of Damocles over Other public cloud users heads. If they have mysterious filesystem issues Oracle will ask for a supported configuration or else will ask the customer to ensure the issue is not caused by the  infrastructure / provider by running it on a known good setup . 

So the message I am trying to make here based on the manpower we had to expend and the issues we had to face ( and I didn't even go into the challenges of explaining how EBS works to teams who think everything can be run as IaaC ! ) there are many reasons that OCI is a way better fit for EBS even if you are running a simplistic non RAC setup in production. Of course if you are running RAC on premise and want to go to public cloud there is no other certified option than OCI.  

Any organization today should have a multi-cloud strategy with at least Azure and Oracle if they have Microsoft and Oracle workloads in their technology mix. If they have EBS then OCI should be hands down the first choice just for the ease of Support.