Containerization architecture

In a Pega environment, containerization refers to running Pega Platform and selected supporting services in Docker containers managed by Kubernetes while integrating with externalized services.

A containerized deployment requires explicit architectural decisions, including:

• Separating workloads into tiers
• Scaling each tier independently
• Storing persistent state outside ephemeral containers
• Deploying releases while minimizing service interruptions
• Monitoring the environment
• Applying client-specific configuration without modifying the container image

Your role includes reviewing these decisions even when a platform engineering team manages the Kubernetes cluster. Containerization supports repeatable deployments, continuous integration and continuous delivery pipelines, infrastructure portability, and controlled configuration. These benefits depend on appropriate platform engineering, operational governance, security controls, and service ownership.

Pega Platform deployment architecture has moved from traditional application-server installations toward a containerized model based on Docker and Kubernetes.

In a virtual machine-based model, application-server nodes connect to shared infrastructure. Updates and environment-specific configuration can require changes to individual nodes.

In the containerized model, Kubernetes manages Pega Platform pods. The architecture separates runtime workloads from persistent services and supports declarative configuration, workload scaling, and automated container lifecycle management.

The following diagram contrasts the legacy 'before' state, which is marked by tightly coupled infrastructure and complex update processes, with the modern 'after' state, where containerization simplifies deployments, reduces operational complexity, and enables greater agility, scalability, resilience, security, and alignment with contemporary microservice-driven software practices.

Docker packages Pega Platform and its runtime dependencies into portable container images. Using the same image across environments reduces configuration differences between deployments.

Kubernetes manages the deployment, scaling, restart, placement, and lifecycle of these containers. It can distribute Pega Platform pods across available cluster resources according to the deployment configuration.

For more information, see Understanding the Pega Platform deployment architecture.

A containerized Pega deployment separates responsibilities across runtime containers, persistent services, backing services, and external services. For example:

• Pega Platform runs in containers that include the supported Apache Tomcat application server and required runtime components.
• The deployment connects to an external relational database.
• Backing services, such as the Search and Reporting Service, run separately and can have independent lifecycle and scaling requirements.

This separation supports workload scaling and fault isolation. Kubernetes can restart or replace an application pod without requiring changes to the complete deployment.

As the environment grows, Kubernetes manages the following functions:

• Pod deployment and lifecycle management
• Horizontal scaling
• Workload placement
• Service networking and load distribution
• Configuration and secret management

In a containerized deployment, a Pega node runs in a Kubernetes pod. A Pega Platform pod contains one or more containers that support the Pega workload. Externalize environment-specific configuration by using Kubernetes resources such as ConfigMaps and Secrets. This approach separates configuration from the container image.

Containers are replaceable runtime units. To preserve information when containers restart or are replaced, Pega stores Rules and application data in the deployment's relational database rather than in the runtime containers. Depending on the deployment architecture, other platform capabilities might also use separately managed stateful services. When runtime processing and persistent storage are separate, Kubernetes can replace failed pods without affecting stored application data.

For more information, see Containerized deployments in Kubernetes environments.

Pega publishes Docker images for Pega Platform and selected supporting services. As an LSA, identify the purpose of each image and the components that remain outside the containerized runtime.

Pega builds the platform and installer images from a base image that includes Ubuntu, Java, and Apache Tomcat.

The following table lists the images identified for Pega Infinity 26:

Kubernetes orchestrates the containers in a Pega deployment. It manages workload placement, scaling, restarts, and lifecycle operations.

Pega publishes Helm charts that generate the Kubernetes objects required for a deployment. Helm values define important aspects of the deployment architecture.

Pega maintains the following Helm charts:

This separation gives cluster-level tools, shared backing services, and Pega Platform independent lifecycles. Different teams can also manage these components.

You can dedicate a backing service to one environment or share it across multiple Pega Infinity environments. Before you select a shared-service model, evaluate:

• Cost
• Failure scope
• Capacity
• Ownership
• Data separation
• Security requirements
• Upgrade and maintenance dependencies

Containerization changes how architects design, deploy, scale, and operate enterprise applications. Instead of managing environment-specific application server installations, teams deploy standardized images and externalize configuration and persistent services.

For Pega solutions, this architectural shift requires LSAs to evaluate workload separation, service dependencies, scaling boundaries, failure domains, and operational ownership.

The containerized model relies on immutable container images. Rather than modifying running environments, teams introduce changes by deploying new image versions.

The following table summarizes the architectural changes:

When you review a containerized Pega deployment, evaluate the complete service chain rather than only the Pega Platform pods. Consider the following questions:

• Does each critical tier have sufficient replicas and failure-domain distribution?
• Are backing services configured to meet the same availability objectives as the workloads that depend on them?
• Is persistent state stored outside ephemeral containers?
• Can the deployment scale each workload independently?
• Are configuration and secrets externalized?
• Does the release process use repeatable images and controlled configuration?
• Are monitoring, recovery, ownership, and maintenance responsibilities defined?

A deployment is not highly available only because it has multiple web-tier pods. Each required backing service must also meet the deployment’s availability and recovery requirements.
 

Check your knowledge with the following interaction: