Skip to main contentMerative SPM on Kubernetes

Frequently Asked Questions

List of the frequently asked question in relation to Merative Social Program Management (SPM) on Cloud

FAQ’s

  • The most common cloud delivery models are Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS).

    All other cloud delivery models (that is, Application Platform-as-a-Service, Database-as-a-Service, Security-as-a-Service, Container-as-a-Service etc.) are specialized variations of one of the three main models.

    At this moment, only IaaS applies to SPM.

  • IaaS is a cloud delivery model that is used to host applications. Most typically, Cloud users self-serve servers over the internet to support their development, test and production workloads without the intervention of a system administrator.

    Once provisioned, these servers are used to host the middleware and the SPM application.

    In this model, software platform (PaaS) or final software (SaaS) are not delivered to end users over the internet in a self-serve manner.

    The intervention of the system administrator is still required to install and configure all the middleware, integrate them, deploy the application, and promote the application and data through the phases of the Software Development Life Cycle (SDLC).

  • Hybrid cloud combines IT resources (compute, middleware, application etc.) on the customer on-premises environment and in the cloud.

    Therefore, for example, SPM hosted on the Azure with integration with legacy systems running on-premises is a hybrid Social Program architecture.

    Important: SPM runtime application is not hybrid - that is, part running on the cloud and part running on-premises.


    In the SPM hosting example mentioned, the Social Program ecosystem architecture is hybrid – that is, some applications running on-premises with SPM running on the cloud.
  • A potential scenario would be the SPM caseworker application running on-premises while the SPM portals such as Citizen Engagement or Providers are running on the Cloud. Although possible, this architecture can lead into complications.

    SPM was designed according to the Shared Database Pattern; therefore, the caseworker application and the portals share the same physical database.

    In such a scenario described, the database would be geographically distant from one of the tenants which could result into issues that are difficult to address:

    • Latency to run high volume of operations against a remote database.
    • Eventual (or even prolonged) unavailability of the remote database due to network glitches.
  • Yes. The integration can be direct site-to-site connection through VPN tunnels or over WAN using HTTP over TLS.
  • No. SPM only supports hosting of containerized architectures on Azure Kubernetes Services or OpenShift.

    SPM provided multi-cloud support through OpenShift in 2020; this means that SPM will support Docker containers hosted on any cloud provider (i.e. AWS, Azure, etc) or on-premises, as long as the underlying container management platform is OpenShift.

    It is also important to remember that AWS EKS is not a container management services based on OpenShift.

  • No. SPM does not support hosting of Docker containers outside Kubernetes, for example, Apache Mesos, AWS Elastic Container Services (ECS) or even directly on virtual machines or bare metal.

    SPM only supports hosting on containerized architectures of SPM on Azure Kubernetes Services or OpenShift.

    SPM does not support Docker containers hosted on virtual machines or bare metal, outside Kubernetes.

  • No. SPM does not support WebSphere Liberty Collectives, regardless of the deployment architecture.

    Although WebSphere Liberty provides support to Collectives, SPM does not support a deployment architecture of the SPM application on WebSphere Liberty Collectives.

  • No. SPM only supports WebSphere Liberty when containerized as Docker images with SPM EAR packages and deployed on Azure Kubernetes Services or OpenShift.

    Important: SPM does not support WebSphere Liberty hosted directly on a virtual machine or bare metal, outside of Kubernetes or OpenShift.


    When the customer opens a ticket for a problem with SPM on WebSphere Liberty, the customer will need to provide the server.xml, Dockerfiles and Helm Charts used to deploy SPM on Kubernetes.

    If the customer is testing SPM on WebSphere Liberty on a virtual machine, the problem needs to be reproducible in Kubernetes and the Kubernetes artifacts (i.e. server.xml, Dockerfiles and Helm Charts) must be provided.

    SPM will not troubleshoot, provide guidance or advise on WebSphere Liberty running on virtual machines or bare metal, regardless if the problem occurred in a development, test, staging or production environments.

  • UBI consists of enterprise-ready and OCI-compliant Linux containers that offer greater security with stricter defaults than general images. By basing the images on UBI, deployment of SPM on OpenShift can be certified.

    For more information, see Red Hat’s Universal Base Image.

  • No. SPM does not support deployment on Kubernetes Services via Operators. You must use Helm.
  • As of Release 20.10.0, combined with SPM 7.0.11.0, the OpenLDAP chart has been removed, as there is no longer a dependency on an external identity provider for elasticity of SPM. If you need access to this chart, refer to an older release of the runbook.