First things first- The following opinions expressed in this post are my own and in no way connected to my employer. 

I’m getting slaughtered with questions about the multiple news stories and releases on the announcement for the Oracle Database Service for Azure, which is a rebrand and updated OCI Interconnect with an Azure Portal overlay in OCI.  It allows the customer to deploy and monitor an Oracle Autonomous database or ExaCC and then have the application tier in Azure.  This is touted as a multi-cloud solution, and I’m going to write this post and point people to it with a very public answer on my technical view of this solution.

If you haven’t had a chance to read the announcement, there were a number released from various sources.  Oracle went big with it and as it benefits them much more than Microsoft, I’m not surprised.

https://blogs.oracle.com/cloud-infrastructure/post/announcing-oracle-database-service-for-microsoft-azure

As most know, I work daily as an Oracle SME on Azure at Microsoft.  I am a Principal Cloud Solution Architect and commonly work on around 25-40 migration projects of Oracle to Azure at a given time.  I started out over four years ago in a North American team until I was brought over to the global Cloud Architecture and Engineering Team over 2 ½ years ago to focus solely on Oracle in Azure and have become a central point of contact for everything Oracle since then.

Today, we have a great number of customers running Oracle on Azure and have built a great opportunity for customers to do more with Oracle than just what it did yesterday.  For our IaaS customers, we have a small group of dedicated folks that ensure they have support and partners like Data Intensity, DataVail, Navisite, as well as incredible storage solutions like ANF and Silk to make it easy for us to handle high IO workloads, even coming from Exadata.  We love our partner Flashgrid, for our few that do need RAC, as they take really good care of their customers, so we never have to worry about them not getting the support they need. This is me and I have an awesome boss and team.  They’re used to me running a bit amok, but I think working in a non-native product at a company takes a bit of a crazy streak anyway.  I love what I do even if I am doing Oracle on Azure, which many find alien, although valuable, at Microsoft.

Here’s my technical view of the offering-

Multi-cloud/Intercloud Is Not for Separation of Application and Database

If we were to ask any DBA to separate the database in one cloud and the application tier in another without the context of a marketing announcement, they would look at us like we’d grown a third head. I’m incredibly surprised that anyone even considers the OCI Interconnect for this use, let alone those currently using it.  Oracle applications, like E-business Suite, Peoplesoft, JD Edwards and Hyperion are incredibly network latency sensitive and to recommend separating their tiers in two separate clouds just is alien to me.  When we deploy these in Azure, we place all tiers in a proximity placement group to let Azure know that they are connected and this ensures that when a resource comes online after changes are made, redeployments, etc. the resources stay close to each other.

I don’t understand the claim of 1ms latency.  I’ve deployed, supported and have been brought in on Severity 1 tickets for the OCI Interconnect.  At no time was the latency 1ms.  At no time was it 2 or 3ms.  It was 8-9ms expected for the application to database connectivity and in my last customer situation, just in the last 2 weeks, depending on the failover, (really failure) it was between 5-38ms.  Optimal ping times are not application latency times.  For OCI Interconnect, we are expected to accept the latency between the peered regions of OCI and Azure and for those customers who desired better response times, we simply migrate the full stack over to Azure, which ensured we could offer the customer .1-.2ms latency times.

Claiming that it’s multi-cloud also chafed Tim and with good reason.  It’s incredibly misleading to market the Azure/OCI Interconnect as a multi-cloud solution.  As Tim is quick to state, “multi-cloud solutions have a good reputation and strategy because they’ve deployed the entire application stack, (i.e. both application and database) to a single cloud and connected it with low latency to another stack running in a second cloud.  It’s commonly intended for applications built upon micro-services and not a divided legacy multi-tier database and application.” 

Most decision makers don’t understand how sensitive application network latency is with these configurations until after they’re neck deep into user dissatisfaction, but I’m on the front line and as I’m here to remove technical roadblocks, avoiding the OCI Interconnect was a path I discovered early on if I wanted my customers to succeed.

Failover Will Most Often Cause Failure

Let’s begin with the location of peered regions between OCI and Azure and if there is a peer in the Azure failover region:

Azure Region	OCI Region	Azure Failover	OCI Peer?
Brazil South	Vinhedo	South Central US	None
Canada Central	Toronto	Canada East	None
East US	Ashburn	West US	Yes, but Phoenix
Germany West Central	Frankfurt	N/A	None
Japan East	Tokyo	Japan West	No
Korea Central	Seoul	Korea South	No
Southeast Asia	Singapore	East Asia	No
UK South	London	UK West	No
West Europe	Amsterdam	North Europe	No
West US	Phoenix	East US	Yes, but Ashburn
West US3	San Jose	N/A	None

 

Most Oracle databases are part of a data estate and need proximity to ALL of the data estate, not just for processing and data loads, but file servers, FTP, etc.  Using EMEA as an example, here’s a real situation and latency between the related cloud resources and failovers, keeping in mind that again, there may be VMs outside of the application and database tier that require low latency to function (optimally):

First Location	Second Location	Latency
On premises	On premises	1ms
Azure North Europe	OCI London	19ms
OCI London	OCI Amsterdam	8ms
Azure UK South, (London)	OCI London	5ms
Azure North Europe	OCI Frankfurt	38ms

 

Taking the times in the above table, if a failover occurs for the primary application or primary database to the first standby or second standby, you can see how impactful it can be and that in no way can you ensure that there is rarely a successful failover situation that will bring success.

In this example, UK South (London) for the application to database in OCI London of 5ms is one of the best I’ve experienced, but if any failover scenario occurred, most weren’t acceptable or failed completely. Using just the first two Azure app tier failover scenarios to the OCI primary and failover locations, you can see impactful the latency became.

App Location	Database Location	Status
UK South(London)	OCI London	5ms Up
UK South(London)	OCI Amsterdam	9ms Up, but heavily impacted
UK South(London)	OCI Frankfurt	19ms down
North Europe(Dublin)	OCI London	9ms Up, but heavily impacted
North Europe(Dublin)	OCI Amsterdam	18ms down
North Europe(Dublin)	OCI Frankfurt	38ms down

 

The network latency, no matter if this is a peered network for Azure and OCI or not, the latency is simply unacceptable, and the architecture is extremely flawed when the natural datacenter deployments vs. peered networks come into play.  This results in a churn rate on customers once a proof of concept (POC) is underway.  Again, I’m here to remove technical roadblocks for customers.

Need Vs. Want

One of the big benefits of this solution was to give customers access to RAC and Exadata, but for most of my customers, they’re either trying to decrease their Oracle licensing costs or leave expensive engineered systems.  Many of these Exadatas were sold even though the customer really didn’t fall into the use case to need one.  We all know this situation, where some salesperson is trying to make his quota and sells a customer “a cloud in a box” and tells them it will solve all their problems.  Once the workload is assessed, we either find it’s not using the engineered system features of HCC (compression) rarely offloading, different flash or even storage indexes and could have gotten just as much benefit from an Oracle Data Appliance (ODA) or the workload can be migrated easily by increasing the memory used and use a high IO storage to balance out from the Exadata.  I really did think it would require more work to “decouple” from Exadata, but you begin to realize, you may not need that big, expensive Exadata box and you also may not need RAC.

The number of database workloads that required RAC for scaling in the four years I’ve been doing assessments- out of over 1000 databases, is SEVEN.  SEVEN databases needed RAC for scaling.  I don’t know how many technologists have also confused WANTING an Exadata or a RAC database vs. needing one, as well.  The desire to work on something that looks cool should never be the reason to recommend or demand something which will add unnecessary complexity and expenditure into technology.

Cloud architecture is different from on premises architecture and hence, we address high availability (HA) differently, but for many, they don’t want to take the time to lift and shift the workload correctly into the cloud and try to replicate everything they have on premises, creating a load of redundancy…and pay for it, too!

Security

In the setup for the ODSA, there’s significant issues around the setup that will make it difficult, if not impossible to get acceptance from large organizations or any organization concerned with strong separation of duties and security protocols.  

In the intro document from OCI to Azure connectivity, to use the ODSA, you’ll need to have an Azure user account with global administration privileges and ownership of the Azure subscriptions you want to link to OCI.  This violates a number of rules about granting the least privileges required to perform actions and will most likely not pass most security policies.

 

The Oracle Database Service for Azure (ODSA) asks customers to separate the application and database tier, bypass best practices around networking, security and this is simply not a good use case for the majority of customers I work with.  At least the Microsoft site has posted use cases where the application and database are in one of the clouds and it’s simply an interconnect used to deliver data between the two systems, with examples for analytics and such.

My goal is to remove technical roadblocks for customers and give them long-term satisfaction with Oracle in Azure.  I’m sure this offering has a use case, but to remove technical roadblocks with my customers means I have to source my decisions on data and experience, not marketing.