- Oracle has responded to reports of significant outages in the Oracle Cloud by making false claims around colocation.
- In this article, we review the statements made by Oracle representatives.
Oracle Cloud uses a lower quality 100% colocated strategy for its data centers. This has been leading to downtime as explained in the article The Problem with the Oracle Cloud and Colocation by Ahmed Azmi of Brightwork Research & Analysis.
“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.”
There are three primary problems with 100% of Oracle’s internal data centers being colocation facilities.
- This provides less quality than the purpose-built facilities of the major cloud service providers like AWS, GCP and Azure.
- Because they not owned by Oracle, Oracle has used this loophole to make its cloud SLA irrelevant as they can always point to the co-location facilities in the case of downtimes.
- Oracle did not tell anyone that these facilities were co-located — we needed to find this out through research.
How Oracle Responded to These Facts
Oracle has followed a concerted effort to lie to their customers about the problems with their 100% co-located data centers. This false information has gone out as a broad communication from Oracle competitive intelligence. And the logic was presented in debates on LinkedIn, responses for which we have copied in this article for analysis.
“….apart from the building itself, everything done by big red. the claims in the article are totally false.” – Selim Daoud
The comment here simply defines what is a co-located facility. Nothing in Ahmed’s article said otherwise. And Ahmed’s article is declared entirely false — which is odd, as the claims were supported by complaining customers, one who wrote an article on LinkedIn describing their problems with outages. This was our response.
“Selim, This article states that the areas of colocation facilities, which means that Big Red would, of course, do everything. That is what colocation means, and the article did not say otherwise. Colocation facilities are a low-quality way to build the cloud. Secondly, they give Oracle a way out of the SLA. Because they can blame the colocation facility. Therefore, Oracle’s SLA that Oracle resources keep talking about is fake. If you disagree, explain why Oracle does not credit downtime. Or do they credit downtime? If so, please explain. Because that would be news to us.
Thus far its difficult to see how you know if Ahmed’s client was complaining about Oracle cloud outages.
Secondly, you seem to be skirting the issue that colocation is not the same thing as building your own purpose-built facility. AWS takes the cloud seriously and builds and owns purpose-built facilities.
When all Oracle resources talk about the cloud, shouldn’t they tell customers the SLA is not real? The information that these facilities are cheap colocation jobs came from Brightwork, not from Oracle. I doubt that Oracle ever brought up the fact they don’t even own their own data centers to Wall Street.
I was able to find this article which describes QTS and AWS for colocation. However, it is geared towards customers that want to use QTS data centers for their hybrid cloud. https://aws.amazon.com/marketplace/pp/B076BL73JG” – Shaun Snapp
Selim Daoud then responded with this comment.
“I was referring to this https://www.wikileaks.org/amazon-atlas/document/AmazonAtlas_v1” – Shaun Snapp
And we replied with the following:
“That is a very interesting document actually. Thanks for sharing that. I noticed Equinix on the list. However, my question is how many of the colocation DCs are listed in that document but are outside of the AWS network? I don’t think AWS claims, for instance, Equinix DCs as part of its network. That is this may be a list all of the DCs that AWS interoperates with. I am open to whatever is the correct interpretation. But I don’t know from looking at this list what that interpretation is.” – Shaun Snapp
Selim Daoud had no response to this comment. Either Selim Daoud had no idea what he was talking about, or he was deliberately providing misleading information that was then picked up by Oracle competitive intelligence, and is now being spread to Oracle customers. This same false information was then shared by an Accenture Sales Director in the following comment.
“https://www.datacenterdynamics.com/news/wikileaks-publishes-list-aws-data-center-locations-colo-providers/” – Laura Reyes
Ahmed Azmi then asked Laura about the Oracle outages.
We then has to explain to Laura, as we had explained to Salim that the list they provided were external locations to AWS, not internal.
“Laura, You are mixing up internal versus external data centers. AWS has a series of internal data centers that are owned by AWS lock stock and barrel. They are custom designed by AWS. But AWS allow connects to collocated centers but that is for hybrid cloud — these are external locations — they are not mentioned as part of AWS’s overall network. This is the same as connecting to a customer’s hybrid cloud on premises. Oracle Cloud is different. 100% of what they list as internal DCs are collocated. So do you see the distinction? Your analysis of AWS’s outages are also incorrect. AWS is relied upon by many customers. When they have an outage people notice. Almost no one notices when Oracle has an outage because so few people use their cloud, which we covered here.
These topics are beyond the capacity of any salespeople I have ever worked with to understand. This deals with proportions, technology, so your comments on these topics will have a high error rate.” – Shaun Snapp
To which Ahmed Azmi added the following.
“Most of these are CDNs Shaun Snapp. They’re used to provide local access points or private connectivity. Everyone uses those even outside the tech world. Netflix has many of these all over the world where they provide services.” – Ahmed Azmi
The most important thing to note is that while the Oracle resources could not come back with any explanation as to why they were presenting external AWS locations as internal. They simply included links to a list of AWS facilities. The official AWS internal facilities are easily viewable at AWS’s global infrastructure page.
On this page, it draws the distinction between internal and edge locations. Even the simplest analysis of the documents shared by the Oracle resources or proponents shows that there an enormous number of locations listed. But AWS does not have anywhere near that many internal locations. Notice there is only one internal location in South America — in San Paulo. Below this, the Edge locations and Regional Caches are listed.
Asia has far more locations than South America. Again, the Edge locations are called out very separately from the internal AWS locations.
Oracle’s entire argument is based upon the idea that it does not know the difference between internal versus edge locations.
Oracle competitive intelligence later took this idea, and distributed this false idea anyway, under the idea that some lie is better than nothing.
- This brings up the topic of how much Oracle’s competitive intelligence group is part of creating falsehoods that are then repeated by Oracle sales reps.
- Also, Oracle partner consulting firms are known as passive repeaters for whatever Oracle says. It is likely that the Oracle consulting partners are repeating this lie to their clients.
The fact is that Oracle has no explanation for why all of their data centers are colocation facilities, for why their break all of their cloud SLAs through the co-location issue, or why they have so many outages with Oracle Cloud.
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 Other Oracle and Database Content
Software Selection Book
Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Information Sources
Mastering Software Selection
Software selection is a form of forecasting, just as any another purchase decision is a forecast of how successfully the purchased item will meet expectations. Forecasting is necessary because it is not feasible to implement each application under consideration before it is purchased to see how it works in the business.
The Importance of Software Selection
What You Can Expect from the Book
Essential reading for success in your next software selection and implementation. Software selection is the most important tasks in a software implementation project, as it is your best (if not only) opportunity to make sure that the right software the software that matches the business requirements is being implemented. Choosing the software that is the best fit clears the way for a successful implementation, yet software selection is often fraught with issues, and many companies do not end up with the best software for their needs. However, the process can be greatly simplified by addressing the information sources that influence software selection.
This book is a how-to guide for improving the software selection process and is formulated around the idea that much like purchasing decisions for consumer products the end user and those with the domain expertise must be included. In addition to providing hints for refining the software selection process, this book delves into the often-overlooked topic of how consulting and IT analyst firms influence the purchasing decision and gives the reader an insider’s understanding of the enterprise software market. By reading this book you will:
- Learn how to apply a scientific approach to the software selection process.
- Interpret vendor-supplied information to your best advantage.
- Understand what motivates a software vendor.
- Learn how the institutional structure and biases of consulting firms affect the advice they give you, and understand how to interpret information from consulting companies correctly.
- Make vendor demos work to your benefit.
- Know the right questions to ask on topics such as integration with existing software, cloud versus on-premise vendors, and client references.
- Differentiate what is important to know about software for improved “implement-ability” versus what the vendor thinks is important for improved “sell-ability.”
- Better manage your software selection projects to ensure smoother implementations.
- Chapter 1: Introduction to Software Selection
- Chapter 2: Understanding the Enterprise Software Market
- Chapter 3: Software Sell-ability versus Implement-ability
- Chapter 4: How to Use Consulting Advice on Software Selection
- Chapter 5: How to Use the Reports of Analyst Firms Like Gartner
- Chapter 6: How to Use Information Provided by Vendors
- Chapter 7: How to Manage the Software Selection Process
- Chapter 8: Conclusion
- Appendix a: How to Use Independent Consultants for Software Selection