A software as a service provider had built its application on one public cloud but ran a demanding Oracle database workload that performed best, and cost least, on Oracle Cloud Infrastructure. Moving the whole application to OCI was not attractive, because the team's skills and tooling were built around its existing cloud, yet leaving the database where it was meant paying a premium for performance it could get more cheaply elsewhere. This case describes how the provider built a multicloud architecture using the OCI and Azure interconnect, and the low latency result it achieved.
It is part of our OCI case studies and benchmarks cluster, and it shows the multicloud patterns from our workload guides applied to a real architecture. The client is anonymised by sector.
The situation
The provider's application tier ran on Azure, where the team was experienced and the surrounding tooling was established, and there was no appetite to relocate that estate. The database tier, however, was an Oracle workload whose performance and licensing economics were materially better on OCI, particularly with the database services Oracle offers there. The provider faced a choice that looked binary: move everything to OCI and disrupt the team, or keep everything on Azure and overpay for the database.
The binary framing was the problem. What the provider actually wanted was the application where its people were productive and the database where it ran best and cost least, which is a multicloud requirement. The obstacle to multicloud is usually the network between the clouds, because a database tier and an application tier that talk constantly cannot tolerate the latency of traffic crossing the public internet between providers.
What we did
We designed an architecture that kept the application on Azure and placed the database tier on OCI, connected by the dedicated interconnect that links the two clouds. That interconnect provides a private, low latency, high bandwidth path between OCI and Azure, which is what makes splitting a chatty application and database across the two clouds viable rather than merely possible. Without it, the latency between tiers would have made the design unworkable.
The database tier was built on OCI to a secure, performant design, the network on both sides was configured so the tiers communicated privately over the interconnect, and the whole arrangement was defined as code so it was repeatable and well understood. The result let the provider keep its application team productive on Azure while running the database where it performed best and cost least on OCI.
The OCI architecture used
On the OCI side the database tier ran in a secure segmented network, sized for the workload, with the interconnect terminating into the provider's OCI network so traffic from the Azure application reached the database privately. On the Azure side the application connected over the same private path, so from the application's point of view the database behaved as if it were local despite running in a different cloud. Monitoring spanned both sides so the team could see the health of the whole path.
This follows the design in our multicloud and hybrid workload guide, and it relies on the network engineering covered in our OCI networking solution, because the quality of the private path between clouds is what determines whether a multicloud split is a clean architecture or a constant performance complaint.
| Tier | Cloud | Why |
|---|---|---|
| Application | Azure | Team skills and tooling already there |
| Database | OCI | Best performance and licensing economics |
| Connectivity | OCI Azure interconnect | Private, low latency path between tiers |
| Observability | Both clouds | See the health of the whole path |
The measurable result
The interconnect delivered the low latency the design needed, so the application on Azure talked to the database on OCI with latency low enough that the split was transparent to users. The provider ran its Oracle database workload on the cloud where it performed best and cost least, while keeping its application team productive on the cloud they knew, capturing the benefit of both without the disruption of consolidating onto one.
The economic gain came from running the database tier where its performance and licensing were most favourable, and the organisational gain came from not forcing the application team to relearn a new cloud. The design proved that multicloud, often discussed as an aspiration, can be a concrete and well performing architecture when the network between the clouds is engineered properly. The resilience dimension connects to our bank uptime case and the wider case studies pillar.
Multicloud as a deliberate choice
The lesson is that multicloud works best as a deliberate placement of each workload where it runs best, not as an accident of history or a hedge for its own sake. The provider chose to split because each tier had a clear best home, and the interconnect made that split practical. Multicloud pursued without that clarity, or without the network to support it, tends to add cost and complexity rather than remove them.
Designing multicloud architectures that genuinely pay off, where the placement is reasoned and the connectivity is sound, is the work of our networking and multicloud practices. As across the case studies, the right architecture follows from the organisation's real situation rather than from a fashion.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.