Application deployment and design decisions

Pega works the same regardless of the environment in which it is running. Pega runs the same on Pega Cloud™ as it does on a customer cloud (such as Amazon Web Services (AWS) or Google Cloud) as it does on-premise. No matter the environment, Pega follows the standard n-tier architecture that you might already recognize.

Pega is software that writes software. You can run your application anywhere or move it from one environment to another. For example, you can start building your application on a Pega Cloud environment, then move your application to an on-premise environment. The application functions the same way.

Consider these two environment variations when designing your application:

• Requirements to deploy an enterprise archive (.ear)
• Requirements to use multitenancy

Pega can be deployed as an enterprise archive (.ear) or a web archive (.war). You must use an enterprise (.ear) deployment if you have one or more of the following requirements:

• You need to use message-driven beans (JMS MDB) to handle messaging requirements.
• You need to implement two-phase commit or transactional integrity across systems.
• You need to implement Java Authentication and Authorization Service (JAAS) or Java Enterprise Edition (JEE) security.
• You need to use the Rule-Service-EJB rule type.
• You have enterprise requirements that all applications run on a JEE-compliant application server.

Pega recommends the deployment of an .ear file, but you also can use a .war deployment if you are running on Tomcat.

For a listing of supported application servers and corresponding deployment archive types, see the Platform Support Guide.

Multitenancy allows you to run multiple logically separate applications on the same physical hardware. Doing so allows using a shared layer for common processing across all tenants yet allows for isolation of data and customization of rules and processes specific to the tenant.

Multitenancy supports the business processing outsourcing (BPO) model using the Software as a Service (SaaS) infrastructure. For example, assume the shared layer represents a customer service application offered by ServiceCo. Each partner of ServiceCo is an independent BPO that provides services to a distinct set of customers. The partner (tenant) can customize processes unique to the business and leverage the infrastructure and shared rules that ServiceCo provides.

When designing for multitenancy, consider:

• Release management and software development life cycle – The multitenant provider must establish guidelines for deploying and manages instances and work with tenants to deploy, test, and monitor applications.
• Multitenant application architecture – The multitenant provider must describe the application architecture to the tenants and explain how tenant layers can be customized.
• System maintenance – Maintenance activities in multitenancy affect all tenants. For example, when a system patch is applied, all tenants are affected by the patch.
• Tenant life cycle – The multitenant provider and tenant must work together to plan disk and hardware resources based on the tenant's plans for the application.
• Tenant security – The two administrators in a multitenant environment include the multitenant provider administrator and the tenant administrator. The multitenant provider sets up the tenant and manages security and operations in the shared layer. The tenant administrator manages the security and operations of the tenant layer.

Read how hybrid-tenancy is replacing single and multi-tenancy on the cloud.

For more information on multitenancy, see the latest available Multitenancy Administration Guide: