What you should know: I am currently working for Orbit Cloud Solutions as Cloud Advisor, but any posts on this blog reflect my own views and opinions only.
In the past, I have written several posts about the interconnect between Oracle Cloud (OCI) and Microsoft Azure. In most cases, the real reason for using this interconnect is to host databases in OCI. In contrast, Azure is used as the primary cloud environment to run applications and other components. This was a great solution for some cases, but had several drawbacks for companies that wanted to run their Oracle databases in the cloud without the hassle of having to deal with a multi-cloud environment. Oracle has now jumped over its own shadow and introduced Oracle Database Service for Azure (ODSA), a new PaaS-style way to run databases in OCI and hide much of the complexity of the interconnect from Azure users. I can not overstate the strategic importance of this and will go into more detail in another post. For now, though, I’d like to take a closer look at ODSA and its implementation.
Prerequisites
Luckily, there are not many prerequisites for trying out ODSA.
On the Azure side, you need an organization account with administrative rights that come with several roles like Global Administrator (see https://docs.oracle.com/en-us/iaas/Content/multicloud/prerequisites.htm). If you are tinkering around with your personal Azure account, you can easily create an organization in Azure Active Directory. I’d recommend creating a separate subscription for setting up ODSA. And then, you need a VNet with which the ODSA OCI network will be peered.
On the Oracle side, you do not even need a subscription before starting with ODSA – you can create it during the setup. If you already have a subscription, it should work. Unless you are one of the unlucky few like myself with an older subscription that has not (yet) been upgraded their IAM to support identity domains. You will either have to get in touch with Oracle support or be creative.
Setup process
Setting up ODSA is a smooth and streamlined experience if all prerequisites are met. You open https://signup.multicloud.oracle.com/azure and will be guided through a couple of steps to authorize the setup in Azure and Oracle.
Once everything is finished, you will be redirected to the ODSA console.
You can deploy your databases now.
Resources created in the background
But before that, let’s first take a look at what happened when the setup of ODSA was done. An excellent overview of the general setup can be found in Oracle documentation.
Azure
In Azure, a couple of resources are created. First, there are three enterprise applications.
- Oracle Database Service Setup Assistant (Temp)
- Oracle Database Service
- MultiCloud_OCI_Azure_Federation_*
With these enterprise applications, a couple of new groups are created in Azure AD.
Most other resources that have been created are probably hidden well.
OCI
For all resources created by ODSA, a compartment CloudLink_Azure_* is created that has subcompartments for each Azure resource group that is linked to ODSA. All resources created for ODSA can be found in these compartments. This includes policies, virtual cloud networks, network components such as a Dynamic Routing Gateway, and of course, the databases.
Interconnect
The heart of ODSA is the managed interconnect between OCI and Azure, which is created whenever the deployed database needs it. Note: This means that for an Autonomous Database, you will not get a dedicated interconnect as it uses public Internet resources. For other database deployments like Oracle Base Database, there will be an interconnect. Unfortunately, I can not tell if there is a shared interconnect in the background for multiple tenancies or if you will get a dedicated interconnect.
So far, you have seen only what is created with the initial setup. But it is the databases that we are interested in.
The good, …
First, let us start with the good stuff that comes when creating databases with ODSA.
Managed Oracle databases
Of course, the most significant advantage of using ODSA is the easy access to the Oracle DB deployment options available in OCI from an Azure subscription.
I won’t go into much detail here. Still, if you rely on Oracle databases, these options might remove some of the biggest headaches you get from deploying Oracle databases in the cloud, namely the correct licensing. Besides removing this barrier that Oracle created, there are some technical benefits like using autoscaling databases or the high-performance Exadata database platform.
Azure Integration
Now, if Azure is your primary cloud provider, then ODSA looks like your typical 3rd party service. It does not fit perfectly with the native Azure services Microsoft provided, but a substantial effort has been made to integrate it nicely. For example, the ODSA console was made to look and behave as you’d expect from Azure.
Some amenities come with ODSA that Oracle doesn’t tell us about in the official documentation, but only in a blog post: When a database gets deployed from ODSA, a new resource group containing several components is created in Azure.
Azure dashboard for databases
In this resource group, you first get a predefined Azure dashboard containing a wide range of metrics relevant for checking the health and performance of your database.
Cloud events in Azure
Then you get an event source to use with Azure Event Grid that provides the cloud events emitted by the databases deployed with ODSA. These can come in handy for handling infrastructure events in Azure, e.g., when a database update has been started or finished.
Metrics in Azure
And finally, there are some metrics for checking the health of the integration. This more or less shows if there are issues with the interconnect but gives little insight into the database’s status.
Egress traffic included
And then there is the advantage of having all egress traffic on the interlink covered by ODSA. It is crucial that you do not have to think about traffic between your application and the database it is using, so thats a big improvement over the old interconnect.
The bad, …
If there is light, there usually is shadow too. ODSA is no exception here.
Robustness of automation
My chief complaint is that the implementation of the processes to set up a DB and create the interconnect is not as robust as you’d expect. For a service aiming at customers that do not want to get involved with managing OCI environments themselves, the process seems somewhat brittle and has its caveats.
For example, I can bring up a situation I experienced when trying to create a new Oracle Base Database on a VM using the ODSA console. After several minutes of setting up resources in OCI, the database deployment failed. And this literally is all the information you get in the ODSA console.
So what to do next? From the ODSA console, you cannot restart a failed deployment. And when trying to deploy another Oracle Base Database to the same Azure VNet, you will find out that only a single Base Database can be deployed to one VNet. So simply ignoring the failed deployment and starting over again with a new deployment will fail too. Each failed deployment leaves a load of resources in the compartment that is not cleaned up after a failed deployment and needs to be removed before trying again. Cleaning up manually will require some experience with OCI.
To get more details, I had to jump to the OCI console and look into the logs there. Even there, I could not find much extra information indicating the reason for the failed deployment. So I was left alone to find out using trial and error what works and what doesn’t. (In case you wondered why my deployments failed: Eventually, I discovered that the only VM shapes that worked for me were Standard.E4.Flex).
Experiencing issues like this collides with the premise that the complexity of the interconnect and handling DB setup could be hidden from the user.
Limits for number of Base Databases
As mentioned above, there is this limit of a single Base Database (i.e., Oracle DB instance installed on a VM or bare metal) per Azure VNet. I cannot think of a good reason for doing this apart from making the automation part easier to manage for Oracle.
But for real-world use cases, there is a need to have several DB instances deployed to a single VNet; think of a couple of OLTP-style databases and a data warehouse. Fixing this requires some OCI experience or messy workarounds in Azure.
And the ugly.
Then there are some aspects that are not bad per se but require additional effort.
Deploying using IaC
Another drawback I see is that I could not find support for deploying ODSA databases from code. There are no terraform or ansible resources that would help you build a new environment from scratch with IaC that includes an ODSA database, which is ok for scenarios where you set up your Exadata to host your legacy PL/SQL applications once and then manage it the same way you did on-premises.
If you were thinking of creating environments that include Oracle DBs on the fly (e.g., an environment used for training), then you are stuck manually creating them in the ODSA console if you need a new CDB. PDBs could be created using IaC in OCI but will not be visible in the ODSA console. So there is a workaround here.
Automation
To automate DB tasks like shutting it down at night and starting again in the morning, you have to use OCI tools like the CLI or include the OCI SDK in your automation code. That’s perfectly fine, but the team still requires some OCI skills.
Conclusion
After taking a closer look at ODSA, I have mixed feelings. First, I think it could be a real game changer for migrating Oracle databases to cloud environments. If it works, you get access to a managed Oracle database in your Azure environment without the limitations Oracle imposes on other solutions.
And that leads me to the things that give me headaches: If the automation provided fails, you do not have a lot of guidance on how to fix the problem. There are limitations ( e.g., the number of base databases per VNet) that will break some typical enterprise use cases. Currently, ODSA feels like an MVP that still needs some support from external consultants with experience with OCI and Azure or directly from Oracle for production use.
ODSA has a lot of potential, and I like the direction it’s going. Ultimately, though, Oracle still has some work to do to reach the point where ODSA is as easy and secure to deploy as a native Azure PaaS solution.