E Business Suite on OCI Architecture

Oracle E Business Suite is a multi tier application that was designed for fixed data center hardware, and the most common reason an EBS estate underperforms on Oracle Cloud Infrastructure is that it was moved without rethinking its architecture for the platform. EBS will run on OCI as a straight copy of its on premises layout, but it runs far better when its tiers are mapped deliberately to OCI services, networks, and availability constructs.

This article sets out a reference architecture for E Business Suite on OCI: how the database and application tiers map to OCI services, how the network should be designed, how to build high availability and disaster recovery, and what the operating model looks like. It is the architectural companion to our guides on migrating EBS to OCI and the wider running Oracle applications on OCI series.

The EBS tiers and how they map to OCI

E Business Suite has two principal tiers: the database tier and the application tier. The database tier holds the EBS database. The application tier runs the concurrent processing, the forms and web services, and the rest of the application logic, and in larger deployments there are multiple application tier nodes for capacity and resilience. Users reach the application tier through a web entry point, which on OCI sits behind a load balancer.

On OCI, the database tier maps to a managed database platform: a Base Database service or VM cluster for most estates, or Exadata Cloud Service for the largest and most demanding. The application tier maps to compute instances, one or more, sized to the concurrent and online load. A flexible load balancer fronts the application tier, giving users a single stable entry point and distributing traffic across application nodes. This clean mapping is the foundation; everything else builds on it.

Database tier choices

The database platform choice for EBS depends on the database size, the performance the application demands, and the licensing model. A Base Database service suits small and mid sized EBS estates. A VM cluster suits larger ones that need more capacity or Real Application Clusters for database tier high availability. Exadata Cloud Service suits the most demanding estates, particularly those already running on Exadata on premises, where it offers a natural target and extreme performance.

Because EBS databases can be large and performance sensitive, this choice has a direct effect on user experience and cost. It also interacts with licensing in ways that can change the total cost substantially, which is why the platform and the licensing model should be decided together rather than the platform being chosen first and the licensing worked out afterward.

Network design for EBS on OCI

EBS is sensitive to network design because its tiers communicate heavily, and latency between the application and database tiers directly affects performance. The reference design places the tiers in separate subnets within a virtual cloud network, with the database tier in a private subnet that is not reachable from the internet, the application tier in a private subnet, and only the load balancer exposed in a public subnet or, better, behind a private entry point reached through a controlled path.

Traffic between the tiers is controlled with network security groups, which let you express rules in terms of the tiers rather than fixed addresses. The database tier accepts connections only from the application tier, the application tier accepts connections only from the load balancer, and administrative access is routed through a bastion rather than exposed directly. This layered design keeps the database isolated, which matters because the EBS database is the most sensitive asset in the estate.

Keeping the tiers in the same availability domain, or carefully across availability domains for resilience, also matters because the inter tier latency is part of the performance equation. The network design is not an afterthought for EBS; it is a determinant of how the application performs.

High availability within a region

High availability for EBS on OCI is built at each tier. At the database tier, Real Application Clusters on a VM cluster or Exadata provides resilience against a node failure, keeping the database available if one node is lost. At the application tier, running multiple application nodes behind the load balancer means the loss of one node does not take the application down, as the load balancer steers traffic to the survivors. OCI's fault domains let you place these nodes so that they do not share underlying hardware, so a single hardware fault cannot take out all of them.

This in region high availability is distinct from disaster recovery, which protects against the loss of a whole region. The two work together: high availability handles the common case of a component failing, and disaster recovery handles the rare case of a regional event. Designing both is what gives EBS the resilience it rarely had on premises. Our guide to EBS disaster recovery on OCI covers the regional side in detail.

Disaster recovery for EBS

Disaster recovery for EBS on OCI combines a database standby with an application tier that can be brought up in the standby region. The database is protected with Data Guard, which maintains a continuously updated standby copy in the second region, so the data is current and the recovery point is small. The application tier is defined in infrastructure as code so it can be stood up in the standby region quickly, either kept warm or scaled up from code on failover depending on the recovery time the business requires.

The recovery target the business sets determines how much of the application tier runs in the standby region between disasters. A demanding target keeps a warm application tier ready; a more relaxed target keeps only the database standby and builds the application tier from code on failover. Either way, the recovery has to be rehearsed, because an EBS failover that has never been tested is an assumption rather than a capability. This connects directly to the broader DR discipline in our disaster recovery and high availability on OCI series.

Reference architecture at a glance

This table is the shape of a well architected EBS estate on OCI. The exact services depend on the size and the licensing model, but the structure, isolated tiers, high availability at each tier, and a regional standby for disaster recovery, holds across estates.

Infrastructure as code is essential

EBS environments are notorious for being hand built and undocumented, which makes them fragile and hard to reproduce. On OCI, the right practice is to define the whole environment, network, compute, load balancer, and database configuration, as infrastructure as code. This makes the environment reproducible, which is what enables both disaster recovery, where you rebuild in the standby region from code, and reliable patching and upgrades, where you test changes in an identical environment before production.

It also removes the standby drift problem that undermines so many DR designs, because the standby is built from the same code as production and cannot silently diverge. For EBS specifically, where environments are complex and the temptation to make manual fixes is strong, the discipline of infrastructure as code is what keeps the estate maintainable over time. Our EBS on OCI workload service builds environments this way as standard.

The operating model after go live

A well architected EBS estate still needs a sound operating model to stay healthy. That covers database patching, which OCI's managed database services simplify; application tier patching and upgrades, which infrastructure as code makes repeatable and testable; backup and recovery, which combines database backups with the ability to rebuild the application tier from code; and monitoring across the tiers so problems are caught before users notice. It also covers cost management, because the scalable application tier should be sized to real demand rather than left at peak, which is one of the main savings OCI offers EBS estates. Our guide to upgrading EBS on OCI covers the patch and upgrade side of this operating model.

Bringing the architecture together

A strong EBS architecture on OCI maps each tier to the right service, isolates the tiers with a layered network, builds high availability at every tier, protects the estate with a rehearsed regional standby, defines everything as code, and runs on a documented operating model. Done this way, EBS gains the elastic capacity, real disaster recovery, and maintainability it rarely had on premises. The migration that gets you there is the subject of our guide to migrating EBS to OCI, and the full application context is in the running Oracle applications on OCI pillar.

Sizing the EBS tiers

Sizing EBS on OCI starts with the recognition that the on premises footprint is usually larger than it needs to be, because it was bought for peak and for years of growth. The database tier should be sized to the real performance profile of the EBS database, which the assessment should measure under representative load rather than infer from the on premises hardware specification. The application tier should be sized to concurrent user load and to the batch and concurrent processing demand, both of which vary through the day and across the financial calendar.

This variability is exactly why the application tier benefits from being scalable on OCI. A quarter end close that drives heavy concurrent processing can be met by scaling the application tier up for the period and back down afterward, rather than by permanently running enough capacity to handle the peak all year. Sizing the estate to typical demand with the ability to scale for peaks is one of the main ways EBS estates reduce their cost on OCI compared with the always on, peak sized on premises model.

Backup and recovery design

Backup for EBS on OCI has two halves: the database and the application tier. The database is protected with regular backups, which OCI's managed database services largely automate, and these backups can be replicated to a second region to support disaster recovery. The application tier, because it is defined as infrastructure as code, does not need to be backed up in the traditional sense; it can be rebuilt from code, with the application configuration and any customizations held in version control rather than captured in a file level backup.

This split is a meaningful improvement over the on premises model, where the application tier was often a hand built server that had to be backed up at the file level and restored painfully. On OCI, the database holds the state and is backed up, while the application tier is code and is rebuilt, which is faster and more reliable. The recovery design combines a database restore or standby promotion with an application tier rebuild from code, and the whole sequence should be tested so the recovery time is known rather than assumed.

Where EBS estates go wrong on OCI

The most common EBS architecture mistakes on OCI are predictable. The first is a straight lift and shift that copies the on premises layout without adopting OCI's managed services, scaling, or infrastructure as code, which carries every on premises limitation into the cloud and captures little of the benefit. The second is hand building the environment instead of defining it as code, which recreates the fragile, undocumented estate that made the on premises EBS hard to manage in the first place.

The third is treating disaster recovery as an afterthought, configuring a database standby but never building the application tier recovery or testing the failover, so the estate has the appearance of DR without the capability. The fourth is over sizing by carrying the on premises footprint across unchanged, paying for capacity the workload does not need. Avoiding these four is most of what separates a well architected EBS estate on OCI from a disappointing one, and each of them is avoidable with the disciplines this article describes.

The role of independent advice

An EBS move to OCI involves decisions that sit at the intersection of architecture and licensing, and these are the decisions where an independent view is most valuable. The database platform choice, the licensing model, and the way existing licenses transfer to OCI all interact, and an architecture chosen without understanding the licensing implications can be costly to correct. Because the rules are intricate and the stakes are high, this is an area where independent expertise, free of any incentive to sell more capacity or more licenses, pays for itself. We work alongside independent licensing specialists on exactly this, so the EBS architecture and the licensing decision are made together. For the full application context, see our running Oracle applications on OCI pillar and our EBS on OCI workload page.

Connecting EBS back to on premises

Few EBS estates are fully isolated, and most need to connect back to on premises systems, whether to integrations that remain in the data center, to identity systems, or to users on the corporate network. The network design therefore has to include a reliable, secure path between OCI and on premises, typically a dedicated connection for predictable performance alongside a backup path for resilience. This connectivity is part of the landing zone rather than the application, but EBS depends on it, and its performance and resilience directly affect the application.

Designing this connectivity well, with adequate bandwidth, low latency, and a resilient fallback, ensures that the EBS estate on OCI integrates cleanly with whatever remains on premises during and after the migration. A weak or single threaded connection back to the data center becomes a bottleneck and a single point of failure that undermines an otherwise well architected estate, so it deserves the same care as the application tiers themselves.