PeopleSoft on AWS: Understanding Design Methods and Scaling Functionality

Moving your PeopleSoft application to the AWS Cloud can be a gamechanger as the benefits can revolutionize your IT department. However, the key to getting the most out of an AWS Cloud investment is to methodically design your PeopleSoft application inside the cloud to take advantage of AWS services. To do this, it is important to understand design methods and scaling functionality.

Designing Your Environment

There are two main methods to design a PeopleSoft application inside of AWS Cloud: Shared and Modular.

The Shared Approach is commonly aligned with traditional data center practices. It involves a common virtual server (or a common set of virtual servers) shared by many application instances that share the same CPU and memory resources across the virtual servers. This approach is convenient and similar to what many organizations are accustomed to. The downside? Depending on your applications, this approach can cause performance issues, availability issues if any of the servers need to be rebooted, and patching/maintenance coordination issues since patching/maintenance activities on the shared servers affect all environments. It also will impact your ability to create environment level automation, which is critical for effective management of your environments in the cloud.

The Modular Approach is a style affiliated with modern or cloud-based application architecture design. It allows for more design options that can leverage the power of the public cloud. Instead of building an environment around a common virtual server (or a common set of virtual servers), each environment is created with its own set of servers that are sized according to the needs of that specific environment. This approach does create more to maintain; however, the benefits are well worth the effort.

By using the Modular Approach, the issues with the Shared Approach are addressed as each individual environment is sized based on the requirements of that specific environment. This removes the impact of server resource contention where multiple applications or application instances are competing for the same fixed pool of compute resources. A server reboot only impacts the one environment that needs it, and patching/maintenance activities can be performed at the environment level without impacting other environments. In the end, your environments are inherently more secure because they are isolated from each other and the environment isolation enables you to leverage automation to effectively manage your PeopleSoft environments at the environment level. This provides a more granular level of control to optimize your Cloud architecture.

Scaling Functionality

Once a PeopleSoft system is officially on AWS, the fun begins with the AWS service of auto-scaling. The public cloud allows applications to scale easily and quickly when extra capacity or performance is needed. You no longer need to worry about performance during peak business events, and you only pay for what you use! There are two general ways to scale an application like PeopleSoft in the Cloud: Load and Scheduled.

Load scaling for the PeopleSoft application works best when you have a load that is 10 to 15 percent more than your current setup can handle. You expand in one chunk – temporarily or permanently. This is due to caching architecture of the PeopleSoft application, which limits how quickly it can scale up without causing performance issues.

Scheduled scaling allows you to scale up in advance of a significant event to ensure your environment is ready. This is typically required for applications that have challenges scaling up quickly due to limitations of the application architecture. PeopleSoft’s caching architecture is one such limitation that prevents it from truly auto-scaling like cloud-native applications. To handle large concurrency events, the PeopleSoft application should be scaled up in advance of the event to allow for the initial caching of objects to be completed prior to the significant event taking place.

Also, part of the AWS auto-scaling service is auto-healing. When a server within your environment fails or is not healthy, auto-healing will remove that server and replace it with a new server identical to the old one to keep the application available and performing smoothly. This activity can be so seamless that users often do not realize it is happening.

The move to the public cloud can be a transformative event for your organization. It’s an opportunity to implement new concepts and break down old silos that have prevented growth. The first step is to take the time to fully understand the options and implement the features that make the most sense to your organization.

Designing your environment and auto-scaling are just two of many tips for optimizing your AWS architecture design. To learn more ways to optimize, watch our related webinar here.