PeopleSoft on OCI Architecture

Oracle PeopleSoft has a distinctive multi tier architecture built around the web tier, the application tier, the process scheduler, and the database, and a PeopleSoft estate runs well on Oracle Cloud Infrastructure when each of these tiers is mapped deliberately to OCI services. PeopleSoft will run on OCI as a copy of its on premises layout, but it performs better, scales more easily, and is more resilient when its tiers are placed thoughtfully across OCI compute, database, and networking constructs.

This article sets out a reference architecture for PeopleSoft on OCI: how the tiers map to OCI services, the network design, high availability, and disaster recovery. It is part of the running Oracle applications on OCI series and pairs with our guide to migrating PeopleSoft to OCI.

The PeopleSoft tiers

PeopleSoft separates its work across four principal tiers. The web tier handles user requests and serves the browser based interface. The application tier runs the business logic through the application server. The process scheduler runs the batch processing, reports, and integration broker work. The database tier holds the data. PeopleSoft uses Oracle WebLogic and Tuxedo within these tiers, which is why the architecture and the WebLogic configuration are closely related.

Understanding these four tiers is the starting point for a PeopleSoft architecture on OCI, because the right design follows from the role each tier plays and the demand it places on resources. The web and application tiers serve interactive users, the process scheduler handles batch and integration work that varies through the day and across reporting cycles, and the database is the most sensitive and performance critical asset. Mapping these deliberately to OCI is the foundation of a healthy estate.

Mapping the tiers to OCI

On OCI, the PeopleSoft database tier maps to a managed database platform, typically a Base Database service or VM cluster sized to the database, with Exadata Cloud Service available for the largest estates. The application tier and process scheduler map to compute instances sized to the logic and batch demand. The web tier maps to compute instances behind a flexible load balancer, which gives users a single stable entry point and distributes traffic across web nodes for capacity and resilience.

This mapping gives each tier a platform suited to its role, which is the core advantage over a straight copy of the on premises layout. The web tier gains the ability to scale to user load, the application and process scheduler tiers get compute sized to their real demand, and the database gets a managed platform that simplifies patching and backup. The estate performs better and costs less than an undifferentiated lift of the old servers.

Network design for PeopleSoft

PeopleSoft tiers communicate heavily, so the network design 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, process scheduler, and web tiers in private subnets, and only the load balancer exposed to users. Network security groups express the rules in terms of the tiers, so the database accepts connections only from the application tier and the application tier only from the tiers that need it.

Keeping the tiers close in network terms, within the same availability domain or carefully across domains for resilience, matters because the inter tier latency is part of the performance equation. Administrative access is routed through a bastion rather than exposed directly. This layered design keeps the database isolated as the most sensitive asset while giving the interactive and batch tiers the low latency paths they need to perform well.

High availability within a region

High availability for PeopleSoft 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. At the web and application tiers, running multiple nodes means the loss of one node does not take the function down, with the load balancer steering user traffic to surviving web nodes. The process scheduler can run across multiple nodes so batch work continues if one is lost. OCI fault domains let you place these nodes so they do not share underlying hardware.

This in region high availability handles the common case of a component failing and is distinct from disaster recovery, which protects against the loss of a whole region. Designing high availability at each tier gives PeopleSoft the resilience it often lacked on premises, where redundancy was constrained by hardware. On OCI the redundancy is a design choice. The WebLogic configuration within the tiers is part of this resilience, which is why we cover it in our WebLogic on OCI best practices guide.

Disaster recovery for PeopleSoft

Disaster recovery for PeopleSoft on OCI combines a database standby with the ability to bring up the web, application, and process scheduler tiers in a second region. The database is protected with Data Guard, which maintains a continuously updated standby copy in the second region, so the recovery point is small. The application tiers are defined as infrastructure as code so they can be stood up in the standby region, either kept warm or built from code on failover depending on the recovery time the business requires.

As with other multi tier Oracle applications, the trap to avoid is protecting only the database and neglecting the application tiers, which leaves the estate unable to actually recover because there is nothing in the recovery region to serve users. A sound PeopleSoft disaster recovery design protects all the tiers and is rehearsed regularly so the recovery time is known rather than assumed. The recovery targets set by the business drive how much of the application tier runs warm between disasters.

Infrastructure as code holds it together

PeopleSoft environments are complex, with several tiers and WebLogic and Tuxedo configuration to keep aligned, which makes them prone to the hand built fragility common to Oracle application estates. Defining the whole environment as infrastructure as code, covering the network, the compute for each tier, the load balancer, the middleware configuration, and the database configuration, makes the environment reproducible. This reproducibility is what enables reliable disaster recovery, repeatable patching, and clean environment cloning for testing upgrades.

For an application as multi tiered as PeopleSoft, this discipline is especially valuable, because there are many components that could otherwise drift out of alignment. Defining everything as code removes that drift and turns the estate from a fragile hand build into a reproducible, version controlled asset. Our PeopleSoft on OCI workload service builds environments this way as standard.

Bringing the architecture together

A strong PeopleSoft 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 that covers all the tiers, and defines everything as code so the estate is reproducible. Done this way, PeopleSoft 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 PeopleSoft to OCI.

The database platform choice and the licensing model that goes with it interact closely with this architecture, and they should be decided together rather than the platform being chosen first and the licensing worked out afterward. Because the rules are intricate, this is an area where independent expertise pays for itself, and we work alongside independent licensing specialists so the architecture and the licensing decision are made together. For the wider context, see the running Oracle applications on OCI pillar.

Sizing the tiers to demand

A PeopleSoft architecture on OCI should size each tier to its measured demand rather than to the on premises hardware, which was almost certainly bought for peak. The database tier is sized to the real performance profile, the application tier to the business logic load, the process scheduler to the batch and reporting demand, and the web tier to the concurrent user load. Because these demands vary through the day and across reporting and payroll cycles, the design can size the tiers to typical demand and scale them for known peaks rather than running peak capacity all year.

This demand based sizing is one of the main ways a PeopleSoft estate reduces its cost on OCI compared with the always on, peak sized on premises model. The process scheduler in particular often peaks at specific times, such as a payroll run or period end, and the ability to scale for those windows and back down afterward is far more economical than permanently provisioning for the peak. Getting the sizing right at design time sets the estate up to be economical from the start.

The role of WebLogic and Tuxedo

PeopleSoft is built on Oracle WebLogic and Tuxedo, and the configuration of this middleware is part of the architecture rather than a separate concern. The WebLogic configuration in the web and application tiers affects how the estate scales and how resilient it is, and it has to be designed alongside the OCI compute and networking rather than treated as an afterthought. Tuxedo coordinates the application server processes, and its configuration affects how the application tier handles load. A PeopleSoft architecture that maps the tiers to OCI well but neglects the middleware configuration will not perform as it should.

This is why the architecture and the middleware configuration are designed together, with the WebLogic settings tuned for the OCI compute they run on and the resilience the estate requires. Our WebLogic on OCI best practices guide covers the middleware side in detail, and it applies directly to PeopleSoft because the application depends on WebLogic for its web and application tiers.

Monitoring across the tiers

A PeopleSoft estate on OCI needs monitoring across all four tiers so that problems are caught before users notice them. The monitoring covers the database, the application tier, the process scheduler and its batch work, the web tier, and the load balancer, watching both the health of each component and the performance users experience. Because PeopleSoft spreads its work across tiers and middleware, effective monitoring correlates across them, so a slowdown experienced in the browser can be traced to its real cause in the application tier, the database, or the middleware.

Good monitoring is also what makes capacity management possible, because the demand data shows whether the tiers are sized correctly and where there is room to scale down or a need to scale up. This connects the monitoring to the cost management that keeps the estate economical, and it sits naturally within a managed service where the monitoring is watched and acted on. Our OCI monitoring and observability service covers this across Oracle application estates.