- Oracle presents the Oracle Cloud as if it is a competitive cloud offering.
- In addition to functionality shortcomings, Oracle Cloud has location shortcomings as well.
It all started with a conversation. The customer was angry. I listened, asked a few questions, and decided to investigate. You can read the customer story in his own words here.
The problem is repeated outages with Oracle cloud. Why so many and why do they last so long? Also, the standard practice with AWS, GCP, and Azure is that outages are compensated with service credits. Why are Oracle’s cloud outages different? Why don’t they come with cloud credits!
We decided to investigate and answer three questions:
- Why does Oracle cloud have an unusually high number of outages?
- Why do outages last so long?
- Why customers don’t receive service credits for these outages?
Let us go over each item.
Why Does Oracle Cloud Have an Unusually High Number of Outages?
Oracle cloud is offered in 5 locations: Phoenix, Ashburn, London, Frankfurt, and most recently, Toronto.
Are these data centers owned or operated by Oracle?
The answer is NO.
These are all leased colocation facilities owned and operated by Digital Reality and Cologix. You can read the announcements by these colocation operators in the links provided. Oracle also uses Equinix and other interconnectivity providers. Here’s the announcement from Digital Reality:
And the recent announcement for the Toronto facility from Cologix:
Oracle cloud is entirely made up of leased colocation facilities operated by third-party providers. These third party providers have their own maintenance schedules for systems maintenance, updates, and upgrades. They also experience their own frequent unplanned downtime. Third party downtime adds additional downtime to Oracle’s own planned and unplanned downtimes. Customers have to deal with downtime from Oracle PLUS downtime from third-party colocation providers. This explains the Oracle Cloud’s high frequency of outages.
Why do Outages Last So Long?
When something breaks, there’s no single throat to choke. Oracle support blames the colocation provider and the provider turns around and blames Oracle. The provider often blames an ISP or the interconnect operator. Too many moving parts and no single ownership. This makes problem resolution extremely difficult and time-consuming. Keep in mind that these third-party providers don’t have a private fiber network connecting their facilities to other provider facilities. All communication has to go through the public internet. With so many cross-connects with backbone and regional networks, troubleshooting problems get exponentially harder and take much longer.
Why Customers Don’t Receive Cloud Credits for Outages?
There are two reasons.
First, Oracle cloud SLA doesn’t recognize outages caused by third parties as eligible for service credit. This applies to metered and un-metered services as you can read on page 5, section 3.3, The Definition of Unplanned Downtime.
When downtime, planned or unplanned, is caused by a third party provider, customers get no service credits.
Secondly, Oracle does NOT credit customers for Oracle’s own planned maintenance downtime. It actually says that in the Oracle cloud policy!
This means that downtime caused by Oracle maintenance, updates, and upgrades either for Oracle OCI or customer specific environments doesn’t count toward any customer service credits.
The problem with Oracle’s cloud is Oracle’s low level of commitment to the cloud. This is clear from Oracle’s anemic CAPEX spend on cloud infrastructure compared to other providers like AWS, Microsoft, and Google.
Instead of building and operating their own data centers and private fiber network, Oracle leases colocation facilities from different operators. This introduces a number of problems for customers such as the one showcased here. Namely, an unusually higher number of outages and much longer resolution times. Moreover, Oracle cloud customers do not receive service credits for either planned or unplanned downtime.
The Problem: A Lack of Fact-Checking of Oracle
There are two fundamental problems around Oracle. The first is the exaggeration of Oracle, which means that companies that purchased from Oracle end up getting far less than they were promised. The second is that the Oracle consulting companies simply repeat whatever Oracle says. This means that on virtually all accounts there is no independent entity that can contradict statements by Oracle.
Being Part of the Solution: What to Do About Oracle
We can provide feedback from multiple Oracle accounts that provide realistic information around a variety of Oracle products — and this reduces the dependence on biased entities like Oracle and all of the large Oracle consulting firms that parrot what Oracle says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. Oracle and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. This is how companies end up paying for items which are exorbitantly priced, exorbitantly expensive to implement and exorbitantly expensive to maintain.
If you need independent advice and fact-checking that is outside of the Oracle and Oracle consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our Oracle Cloud Content
AWS and Google Cloud Book
Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.