This article provides answers to frequently asked questions related to third-party externalized service deployment modernization.
Overview FAQs on this topic can be found at Third-party externalized services FAQs on the Pega Docs site.
Additional documentation includes Externalization of services in your deployment, with additional articles for Hazelcast, Elasticsearch, Cassandra, and Kafka.
Answers to frequently asked questions
Third-party externalization
Does Pega provide detailed guidance on how to deploy these externalized services, including information about whether they must be in the same NameSpaces, same Availability Zones, or same networks?
(ALSO: Should externalized Elasticsearch, Cassandra, Kafka, and Hazelcast be started as separate containers, or can they be located on the same Namespace?)
External services should be in separate containers to allow for disparate scaling and maintenance. Other than that, the details are up to the clients' internal policies and guidelines.
Would Pega publish a performance tuning and production operations guide for these externalised services?
Pega documentation contains configuration and sizing guides designed to ensure your externalized service is set up for success with Pega. For example, the Cassandra configuration page and the Kafka configuration page.
What happens when the vendor end-of-life's the version we deployed on even when the version of Pega Platform is not EOL’ed?
Pega is continuously monitoring third party component lifecycles. Each Pega release includes updated certifications and supported versions for third party components. If Pega software is kept current, the supported third party components will be current as well. See the Platform Support Guide for details.
Are we going to provide the same level of Helm documentation for external products?
(Are we going to provide Helm documentation around setting up the externalized services (Kafka/ES)? Partner has asked if we could provide documentation on creating the external-third party containers? That way there is a central documentation/Helm for ALL parts of the Pega architecture rather than only the Pega parts.)
Pega will not be detailing setup for external containers due to the variability of solutions and deployments. There are sample configurations provided for Elasticsearch and Kafka but these are examples.
Would PDC support monitoring these externalised services?
Not at this time. But we are investigating what kind of Pega-specific data about these services would be helpful in PDC and will incorporate this into our roadmap.
Is it true that Infinity '24 and later cannot be upgraded without first upgrading to Pega 8.8 or Infinity '23 (direct upgrade from 8.7.x or earlier is not possible)?
Not exactly. The externalization of the third-party products must be done before updating to Infinity '24, but that externalization can be done at any point from 8.6 onward. Once you have externalized the third-party products (Hazelcast, Cassandra, Elasticsearch, Kafka), you can update directly to Infinity '24 from several prior 8.x versions (8.6, 8.7, 8.8).
Do clients have to move their Pega Infinity to a Docker/Kubernetes setup in order to externalize their third-party services? Can clients externalize on a virtual-machine setup?
Externalization of Kafka, Cassandra, HazelCast, and ElasticSearch is independent of containerized deployments. The ability to externalize has been available since at least Pega Platform 8.6 for those products (and for some it is earlier), so clients can certainly externalize on their virtual-machine setup.
Can you explain the migration model to an upgraded version of the externalised services? Who would be responsible for this?
The external services will be owned by the client (much like the relational database today). They can administer and upgrade it themselves, enlist a partner to help, or use a third party provider.
When clients deploy multiple externalized services or various combinations of these services, will Pega test the combination of those services working together?
Pega is validating versions of these third-party solutions for each Pega Platform version. Combinations of these certified components are supported.
How long would the verification process be for the third-party externalized services?
(If a bug is found in one of the third-party products, and they fix that, how long before Pega supports the updated version of that product? Do the clients have to wait until the next Pega Platform release, which could be a year away?)
The Platform Support Guide addresses this:
In general, stack component vendors manage forward and backward compatibility very effectively. This means that most of the time, the Pega Platform will continue to operate correctly when stack components are upgraded to new patch levels or versions. Pega typically will support deployment on these later versions even if they are not explicitly listed in this guide. Clients are encouraged to upgrade stack components in accord with their IT or business policies, and report any issues via My Support Portal on the Pega Community.
Can clients co-locate the externalized products with their enterprise versions, or are there Pega-specific versions?
Hazelcast is provided by Pega. For Elasticsearch, Kafka, or Cassandra, clients can co-locate these solutions with their enterprise versions - as long as they are versions supported by the Pega platform version they run.
Is there guidance on how to scale the third-party software which the client now must deploy and maintain?
The scalability of these solutions are based on the number of applications, the volume of transactions, the number of cases, the complexity of these transactions. There is not an easy way to predict this growth. Each third-party solution has their own scalability schema: it could be horizontal by allocating more resources (CPU, memory, storage, network, etc.) for each instance or vertical by adding more instances. The best practice is to perform performance and scalability tests to validate configurations, and monitor closely the resources' usage to get alerts when some of them are reaching some thresholds.
How will we be communicating/certifying supported versions of those services for each version of Pega so that customers don’t upgrade them past what will work?
Pega provides the versions of these services that are supported for each version of the platform in the Platform Support Guide.
Hazelcast
Is Hazelcast required for a single node? What would happen if the client did not externalize Hazelcast?
Single node Pega deployments are not supported for any use case other than very simple experimental setups since they have no resiliency to losing a node. Hazelcast is always required for Pega. Once embedded Hazelcast is no longer supported in the Pega Infinity 8.9 release, the system will not initialize without the external Hazelcast service.
Does Hazelcast externalization require Kubernetes?
(Or will Pega provide licensed Hazelcast installation images for non-Kubernetes deployments?)
No. The Pega Hazelcast Docker image can be run in non-Kubernetes deployments.
Elasticsearch
If a client runs ES on AWS, does Pega support that? Given that SRS is between Pega and ES, do we care about how ES is deployed (container, managed service, or EC2) – as long as they have the right ES version, does it matter?
It does not matter. You can refer to the SRS Readme and the Helm charts for backing services to learn how to connect to your Elasticsearch instance.
If the client is using AWS OpenSearch, can SRS connect to that, or will it only support Elasticsearch itself?
Yes, SRS can connect to the Elasticsearch 7.10 version thats running on AWS OpenSearch service, It must be configured to use the legacy Elasticsearch OSS engine, version 7.10.
Saying that, SRS may not be working as per expectation neither with OpenSearch search database nor with AWS OpenSearch service thats running OpenSearch 1.x or 2.x managed versions.
Kafka
Is it possible to configure Infinity without Kafka if the user application does not use the Kafka stream/dataset?
No, Kafka is required for all Pega installations as it is used for internal queuing functionality even when CDH is not in use.
Can we use PubSub instead of Kafka?
[Some of the externalised services listed are not supported in our Google Cloud Platform (GCP) stack. ]
No. Kafka is required and is available on GCP.
Will Pega support Amazon Managed Streaming for Apache Kafka (MSK)?
Pega can connect to any external Kafka with support for configuration settings that is generic across all types of Kafka deployments (MSK, Confluent, Local Kafka, etc.). Pega doesn’t support vendor specific security features (like IAM roles).
Cassandra
Can we use BigQuery instead of Cassandra?
[Some of the externalised services listed are not supported in our Google Cloud Platform (GCP) stack. ]
No. Cassandra is required and is available on GCP.
Is it possible to configure Infinity without Cassandra if CDH is not used?
(If possible, how should the yaml be specifically described, should the Dds section be removed?)
Yes, Cassandra is not required if Customer Decision Hub is not being used. To do so in the yaml file, set cassandra.enabled to false and comment out or remove the DDS connection settings.
Constellation
Is it possible to configure Infinity without Constellation if Constellation UI (Cosmos React UI) is not used?
(If possible, how should the yaml be specifically described, should we set "enabled" to "false"?)
Yes, the Constellation Service is not required if the Constellation UI is not in use. The Constellation Service Helm chart readme describes how to disable it.
