This will NOT be a technical walkthrough on Oracle Database@Azure but rather my opinions and thoughts on how it will shape the Oracle workload destinations when migrating out from on-premises.
Once I get few technical implementations under my belt, I’ll also write some more details on how I see it works and how we need to rethink based on how we’re thinking on it right now.
What is Oracle Database@Azure?
I get this question a lot, one of the reasons being there’s a huge interest on this right now!
It’s exactly what it says, you can now run Oracle Database on actual Azure Region/Availability Zone without restrictions! Solution right now (May 2024) has two offerings, Exadata and Autonomous Database.
When we think on Exadata, it’ll be exactly same setup as OCI Exadata Cloud Service (or Exadata on Dedicated HW on OCI whatever the current name is..), it leverages same APIs and automation as you’ve used to seeing with OCI. Infrastructure, VM Cluster, Database home/DB provisioning is all automated! Same as patching and upgrading.
Once you have an agreement with Oracle, you will be able to provision this through Azure marketplace on your private Azure Vnet. All Oracle Database features are now available for you what you can run on OCI Exadata as well! This includes RAC for Oracle Database as well. Personally, I think this is huge!
Now you have all the Oracle workloads that maybe weren’t considered to be migrated to OCI available to be migrated to Azure as well! Ok, maybe Azure isn’t the right fit for you either so you’ll still have to stay on-premises (which is fine of course), but you’ll have more OPTIONS which is great.
Why should I choose Oracle Database@Azure
I don’t think things work always as we hear vendors to say, OCI is still an awesome platform, but maybe your multicloud strategy hasn’t involved OCI. Maybe you’re Azure first organization and you need to get same Exadata-like performance or you want to run your databases on Oracle Database@Azure. This is when you should consider migrating to Oracle Database@Azure!
I’ve always felt OCI/Azure Interconnect is great fit for utilizing best services from both clouds. However, it’s never been best solution to run your low latency critical workloads how it’s been sometimes made sound like.
If you’ve gone with split-stack architecture (run DB on OCI, app on Azure) – I’m sure there are workloads that work without issues on that but in case issues.. who takes responsibility on those? It’ll be YOU and just YOU.
Even though there are some additional network setup needed with Database@Azure, it’ll still provide you that microseconds latency between app and database. Now, there are definitely things to consider. For example, in OCI we many times utilize same VCN for Exadata and app but in Azure, it’s quite common to use Vnet peering.
Should we use Vnet peering betweem app and database, transit routing (via FW) or have app and DB in same Vnet? Stock answer: it depends! And I think it’s a learning process still for many on how we will architect these solutions.
Another aspect will be consolidation, you can use Exadata on Azure similar as normal Exadatas: As a consolidation platform, maybe you have tens or hundreds of databases and you can now save with licenses and cost by running them on same Exadata.
To summarize common drivers could be:
- Azure being preferred cloud
- Azure having services YOU need
- Database features
- Database latency/performance
- Cost & Consolidation
How will it work technically?
I’m not going to dive deep on this as I don’t have means on showing real life examples, but in short you must have a agreement with Oracle to get Azure private marketplace offer visible. You’ll need to perform some network and IAM pre-requirements such as setting up delegated subnets for Exadata.
After that you provision Infrastructure and VM clusters from Azure side, you can use Terraform and APIs for this. Once VM Clusters are provisioned on the Azure Vnet, you will login to OCI Console or utilize Terraform/OCI APIs to create and manage databases running on those VM Clusters.
VM Clusters will have SCAN address which is resolvable from Azure DNS, so your apps running on Azure Vnets will be able to resolve that SCAN address!
There are also several links available on how to migrate your database to this solution, if you want to do it in a simplified manner – look on using Oracle ZDM!
Summary
I’m betting on Oracle’s strategy on opening these solutions to Azure being a real winner long term! I think it’ll still take some time for folks to adopt this on a wider scale, but gone are the days when we saw Oracle database as a really closed ecosystem.
Some good links for reading below.
Oracle Database @ Azure FAQ: https://www.oracle.com/ca-en/cloud/azure/oracle-database-at-azure/faq/
Onboarding Documentation: https://docs.oracle.com/en-us/iaas/Content/multicloud/oaaonboard.htm
Microsoft Documentation: https://learn.microsoft.com/en-us/azure/oracle/oracle-azure-overview
Migrating to Oracle Database @ Azure: https://blogs.oracle.com/maa/post/oracle-zdm-for-oracle-database-at-azure