Recently Oracle and Microsoft announced availability of their new service – Oracle Database Service for Azure. It raises the level of integration and interoperability between Oracle Cloud and Microsoft Azure. With the new service Microsoft’s customers are able to create and manage Oracle databases created in Oracle cloud and use them for applications located in Azure. That sounds great and moves us one step closer to a real multi-cloud environment. Before proceeding, let me clarify what I mean as the “real” multi-cloud. I mean an environment where different pieces of the same IT service are located in different clouds working as a whole.
Let’s talk about multi-cloud and what kind of architecture challenges people are trying to solve with it. I don’t pretend to cover all the possible reasons or cases and I am not placing them in any particular order . Importance, aspirations and outcome for the multi-cloud strategy can significantly differ from customer to customer.
From my conversations with customers one of the reasons to consider a multi-cloud is minimizing the risks of a total dependency on a single cloud vendor’s technologies. That can be driven by different assumptions, financial or technological but at the end it is supposed to give some level of flexibility and free choice.
The second case is to protect from a vendor technical issues and have a DR (Disaster Recovery) environment in another cloud minimizing risks of a complete cloud failure. We all know that some cloud outages can lead to problems in multiple regions of a same cloud vendor.
And one more reason to use different clouds is some technology or business benefits coming with one or another cloud provider. It can be a unique product or price policy for some components making the business more efficient.
What exactly are we getting with the new Oracle-Azure service? It allows us to have an application in one cloud and the database services in another cloud in the same region. It seems like it is more close to the last listed business case when a cloud vendor has a set of unique offerings. The unique offerings of the Oracle cloud include several database services. It provides benefits of more attractive licensing, a powerful Oracle platform based on Oracle exadata and some unique features such as RAC (Real Application Cluster) which are not available in other public clouds. Let us go through the “pros” and “cons” of such architecture and how Microsoft and Oracle make it attractive to the customers.
As a matter of fact, technically we can create such an architecture for a long time. Oracle has introduced the Azure-Oracle interconnect service in 2019 and I’ve written a blog about it. But during all those years I yet to see an actual production implementation using the service. I saw and participated in tests but it never realized in a production implementation.
In reality it is hard to convince people to put an application in one cloud and the database layer in another when all the best practices say to not only put the database in the same region but in the same availability zone(domain) as the application. It makes a lot of sense from a technical and financial point of view. The traffic between application and database can be quite heavy and sensitive to any increase in latency. Also the egress to another region or cloud can cost significant money. Also people were worried about complicated implementation, monitoring, support, management and how it worked in case of a disaster affecting entire region.
Let’s have a look how Oracle and Microsoft solved those concerns and start from the latency. The latency is time required to get some piece of information from remote site. In the case of Azure-Oracle database services the claimed latency is less than 2 ms and from my tests done in US East/Ashburn regions it is about extra 1.5ms on top of the same traffic if it runs inside the same availability zone. The overhead was measured by running a dummy app inside the same cloud and when one part was in another cloud connected through the Azure-Oracle interconnect. The same tests were repeated using Oracle oratcptest (Doc ID 2064368.1) tool and showed the same extra 1.5 ms for a roundtrip. If the application accepts that overhead the first concern about the latency is addressed. Of course every application is different and everybody has to perform sufficient testing.
The second concern is financial and related to the network egress cost. If you are using the new Oracle-Azure service the traffic between your application in Azure and database in Oracle cloud is free.
The complexity of deployment, management and monitoring were addressed by creating a new portal for Oracle Database Service for Azure (ODSA) and biding OCI groups to Azure AD integrating two identity systems together. And Oracle and Microsoft mentioned about combined support force from Microsoft and Oracle working together.
All that sounds just great and might turn around customers to the new paradigm and try the service but my friend Kelly has raised an important point about DR and how it is supposed to work in the multi-cloud architecture.
Let’s have a look to the Microsoft and OCI regions in North America.
We have four regions with OCI-Azure integration and can easily use it as DR locations.
And it works for US where we have more than one region with the Azure-OCI integration and for Canada when data location doesn’t make a difference.
But for some companies in Canada data residency is highly important. It means the data have to stay on the Canadian soil and, as result, the DR solution has to use regions in Canada.
In Canada we have only one region with Azure-OCI integration located in Toronto. The second region in Montreal has the closest counterpart in Quebec.
As result we have to choose between three solutions:
- The primary site is Toronto. DR for application and database in Azure Quebec.
- The primary site is Toronto. DR for application in Azure Quebec plus DR for the database in Montreal OCI.
- The primary site is Toronto. DE for application and database in OCI Montreal.
Let’s go through pros and cons for each solution. I created a small table to put different arguments together.
| DB and App DR – Azure Quebec | DB DR – OCI Montreal + App DR – Azure Quebec | DB and App DR – OCI Montreal | |
| Net Latency | Low | High | Low |
| Oracle Cloud Databases: ADB Exadata JSON | Not Available | Available | Available |
| Unique Azure applications | Available | Available | Not Available |
| DR DB replication traffic (standby) | From OCI to Azure – $$ | OCI to OCI | OCI to OCI |
| App – DB traffic | Inside Azure region | Between Azure and OCI – $$ | Inside OCI region |
| DB Management | Manually | OCI tools | OCI tools |
I didn’t include some other important factors as a connections stability, support and licensing leaving primarily technical points. From the table we can see that all three solutions have their pros and cons.
In my opinion the DR problem should be solved in principal by either adding another region with Azure-OCI integration or allowing data flow over the border. If neither of this conditions is feasible then the application is not ready for the multi-cloud architecture.
A short summary. I think Oracle and Microsoft have done good job making a significant step toward multi-cloud feature and it might be a workable solution for some implementations. But it still have some gaps such as DR strategy for applications in countries outside of US and where the data residency is one of the requirements. Hopefully that will be addressed or we just accept that some apps are not going to use multi-cloud.