Frequently Asked Questions
List of the frequently asked question in relation to Cúram 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 Cúram.
- 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 Cúram 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, Cúram hosted on the Azure with integration with legacy systems running on-premises is a hybrid Cúram architecture.
In the Cúram hosting example mentioned, the Cúram ecosystem architecture is hybrid – that is, some applications running on-premises with Cúram running on the cloud. - A potential scenario would be the Cúram caseworker application running on-premises while the Cúram portals such as Citizen Engagement or Providers are running on the Cloud. Although possible, this architecture can lead into complications.
Cúram 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.
- Cúram supports hosting of containerized architectures on Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) and OpenShift. EKS is currently only supported for development and test environments.
Cúram provided multi-cloud support through OpenShift in 2020; this means that Cúram 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, Cúram is supported only on Kubernetes-based platforms and cannot be deployed using alternative container orchestration solutions such as Apache Mesos, AWS Elastic Container Service (ECS), or directly on virtual machines or bare metal. For currently supported architecture refer to the [Architecture Overview](/arch-overview/architecture-overview) page.
Cúram only supports hosting on containerized architectures of Cúram on Azure Kubernetes Services, Amazon Elastic Kubernetes Services or OpenShift.
Cúram does not support Docker containers hosted on virtual machines or bare metal, outside Kubernetes.
- No. Cúram does not support WebSphere Liberty Collectives, regardless of the deployment architecture.
Although WebSphere Liberty provides support to Collectives, Cúram does not support a deployment architecture of the Cúram application on WebSphere Liberty Collectives.
- No. Cúram only supports WebSphere Liberty when containerized as Docker images with Cúram EAR packages and deployed on Azure Kubernetes Services or OpenShift.
When the customer opens a ticket for a problem with Cúram on WebSphere Liberty, the customer will need to provide the server.xml, Dockerfiles and Helm Charts used to deploy Cúram on Kubernetes.If the customer is testing Cúram 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.
Cúram 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 Cúram on OpenShift can be certified.
For more information, see Red Hat’s Universal Base Image.
- No. Cúram does not support deployment on Kubernetes Services via Operators. You must use Helm.
- As of Release 20.10.0, combined with Cúram 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 Cúram. If you need access to this chart, refer to an older release of the runbook.