Benefits from moving Applications to Cloud:
Cost

- Reduce on-premises infrastructure spend and predictable costs based on usage.
- Eliminate the hardware refresh and capacity planning vicious cycle
Innovation

- Accelerate business transformation and innovation by getting new applications out quickly
- Consolidate Oracle Applications silos with disparate on-premises hardware into a single cloud infrastructure
Transformation

- IaaS provides instant access to resources, not infrastructure procurement headaches
- Focus on strategic priorities, not managing hardware and software
Performance

Predictable performance supports workloads from cloud-native to mission critical Applications and Databases in the Oracle Cloud
- Next generation IaaS performance matches and often exceeds on-premises deployments
Choosing a deployment strategy with Sedulous Tech Solutions that fits!
Oracle Cloud Infrastructure is a set of complementary cloud services that enable you to build and run a wide range of applications and services in a highly available hosted environment. Oracle Cloud Infrastructure offers high-performance compute capabilities (as physical hardware instances) and storage capacity in a flexible overlay virtual network that is securely accessible from your on-premises network.
JD Edwards EnterpriseOne application release 8.12, 9.0, 9.1, and 9.2.
Before you begin planning to deploy or migrate your JD Edwards EnterpriseOne application, identify if Oracle Cloud Infrastructure supports the combination of JD Edwards EnterpriseOne application release, JD Edwards EnterpriseOne tools release, and the operating system on which you want to run your applications.
JD Edwards EnterpriseOne application release 9.2 with JD Edwards EnterpriseOne Tools release 9.2.x. It supports manual and automated installation of JD Edwards EnterpriseOne components on Oracle Linux and Windows operating systems.
JD Edwards EnterpriseOne application release 9.1 with JD Edwards EnterpriseOne Tools release 9.1.x or 9.2.x. It supports only manual installation of JD Edwards EnterpriseOne components on Oracle Linux and Windows operating systems.
JD Edwards EnterpriseOne application release 8.12 with JD Edwards EnterpriseOne Tools release 8.98.4. It supports only manual installation of JD Edwards EnterpriseOne components on Windows operating system.
Considerations for Deployment on Oracle Cloud Infrastructure
Private or Public Subnets
Create instances in a private or a public subnet based on whether want to permit access to the instances from the internet. Instances that to create in a public subnet are assigned a public IP address and you can access these instances from the Internet. Can’t assign a public IP address to instances created in a private subnet. Therefore can’t access these instances over the internet.
The following image below shows a virtual cloud network (VCN) with public and private subnets. The VCN contains two availability domains, and each availability domain contains a public and private subnet. The web servers are placed in the public subnet in this image, so the web server instances have a public IP address attached to it. Can access these Oracle Cloud instances in the public subnet from the internet by enabling communication through the internet gateway (IGW). Will have to update the route table to enable traffic to and from the IGW. To permit traffic to the web servers from the internet, must create load balancers in the public subnet. To access your instances from the internet, also need to create bastion host in public subnet and access the bastion host from the IGW.
Some benefits unique to public cloud include:
- Low upfront costs – Public clouds are faster and cheaper to get started as they provide users with a
- Low barrier to entry with no need to procure, install, and configure hardware or software. Economies of scale – Large public clouds enjoy economies of scale in terms of equipment
- Purchasing power and management efficiencies which often results in lower fees for customers. Outsourced management – Public clouds do not require IT personnel to manage, administer,
- Update, and patch. Users rely on the service provider instead of the internal IT department. Operating expense – Public clouds are paid out of the operating expense budget, most often by the
- Users’ line of business, not the IT department. Capital expense is avoided, which can be an advantage in some organizations.
The database servers are placed in the private subnet, can access Oracle Cloud instances in the private subnet from data centers by connecting through the dynamic routing gateway (DRG). The DRG is the gateway that connects on-premises network to cloud network. To enable communication between the DRG and the customer-premises equipment, use IPSec VPN or Oracle Cloud Infrastructure Fast Connect. Also have to update the route table to enable traffic to and from the DRG.
Benefits that are unique to private cloud include:
- Greater control of security, compliance, and quality of service – Private clouds enable IT to maintain control of security (data loss, privacy), compliance (data handling policies, data retention, audit, regulations governing data location), and quality of service (since private clouds can optimize networks in ways that public clouds do not allow).
- Easier integration – Applications running in private clouds are easier to integrate with other in-house applications, such as identity management systems.
- Lower lifetime costs – Private clouds with sufficient scale may be cheaper over the long term
- Compared to public clouds just as in any rent vs. buy financial decision. According to several analyses, the breakeven period is most often between two and three years. Capital expense and operating expense – Private clouds are funded by a combination of capital
- Expense and operating expense.

Scenario 1: Deploy All Instances in Private Subnets
We recommends deploying all instances in private subnets for production environments where there are no internet-facing endpoints. This type of deployment is useful when want to have a hybrid deployment with the cloud as an extension to existing data centers.
In this deployment, all the instances including application and database servers are deployed in a private subnet. A public IP address can’t be assigned to instances created in a private subnet, so can’t access these instances over the internet. To access application servers from on-premises environment in this configuration, can:
- Configure an IPSec VPN tunnel between data center and Oracle Cloud Infrastructure DRG before provisioning the application servers.
- Create a bastion host in this configuration, and then access all the servers in private subnet from the bastion host.
Scenario 2: Deploy Instances in Public and Private Subnets
Deploy a few instances in a public subnet and a few instances in a private subnet. This type of deployment is useful when the deployment includes internet-facing and non-internet facing endpoints.
In this configuration, some application instances are placed in a public subnet, and others are placed in a private subnet. For example, may have application instances serving internal users and another set of application instances serving external users. In this scenario, place the application instances that serve internal traffic in a private subnet, and place the application servers that serve external traffic in a public subnet, can also set up a public load balancer on the internet-facing application instances, instead of placing the application servers that serve external traffic in a public subnet. If place the bastion host in a public subnet, then the bastion host is assigned a public IP address, and can access it over the internet, can access instances in the private subnet through the bastion server.
Scenario 3: Deploy All Instances in Public Subnets
We recommend this deployment for quick demonstrations or for production-grade deployments with no internal endpoints. This deployment is suitable only if don’t have own data center, or can’t access instances over VPN, and want to access the infrastructure over the internet.
In this deployment, all the instances including the application and database instances are deployed in public subnets.
Every instance in the public subnet has a public IP address attached to it. Although instances with public IP addresses can be accessed over the internet, can restrict access by using security lists and security rules. For performing administration tasks, we recommends that place a bastion host in this configuration. In this scenario, would not open administration ports to the public internet, but rather open the administration ports only to the bastion host and setup security lists and security rules to ensure that the instance can be accessed only from the bastion host.
