You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Blueriq can be used in a hosting environment where high availability is a requirement. This article will talk about the why, the when and the how of setting up Blueriq services in with aforementioned requirements in mind.

Why to Setup Failover

Let's first explore how Blueriq approaches the topic of high availability.

With Blueriq your end users are using a Blueriq application that was designed in our design environment and it runs on a Blueriq Runtime instance. May it be a simple forms application, several webservices to an entire case management system. All of these Blueriq projects will be hosted and will be running through a Blueriq Runtime.

When this runtime instance has any kind of downtime; maintenance or unforeseen issues, your Blueriq application will naturally not be available anymore. This can become a real problem when you want to minimize downtime on your online services.

Blueriq by its nature is a stateful information system, meaning each end-user using your Blueriq application will have a session that is stored server side. These session are classically stored inside server memory and would be lost if the server goes down.

It should be noted that there is a difference between a highly available system and a scalable system, although there can be some overlap as in making a system highly available might also make it more scalable. The key difference is that in a highly available environment the focus is on retaining state when something goes down whether it is planned or not. With Blueriq this mainly means we keep sessions available even when Blueriq services go offline. When we are talking about creating a scalable environment it would not be necessary to focus on retaining user sessions. This is because a session can be running fine inside a single online service for its whole active time. You could theoretically start as many other instances of a Blueriq service as you need and have all of them manage there own sessions entirely in system memory without much trouble in context of scalability.

This way of managing sessions is called "sticky sessions" and it is the main obstacle in Blueriqs architecture in making it failover ready, but not in making it more scalable.

Therefore making your Blueriq stack highly available and user session data safe, we made Blueriq services store their state in external high performance data stores, in our case Redis. This way the components of Blueriq that have session management can be setup in a failover cluster, therefore enabling redundancy.

When to Setup Failover

Blueriq usually runs in an environment with multiple other hosted applications. It is important to take in account all the variables of your specific solutions needs. The documentation about the subject failover is primarily meant to advise on when and how to use failover. We offer certain functionality and it is up too the professionals implementing the solution too make the decisions on how to use functionality in this solution. How does Blueriq fit in your infrastructure? What technical requirements do you have as a team and organization?

Consider the following when planning your hosting environment setup:

  • Are you running inside a Cloud(like) environment?
  • Are you running inside a containerized (Docker or other) environment?
  • Do you have high availability requirements (I.E. >99% uptimes) with your customers/partners?
  • Do you want to update Blueriq services/models with newer versions while minimizing downtime?*

If any of these questions are answered with a "yes" you might want to consider setting things up in a failover configuration.

Setting Blueriq up with failover support does also bring some downsides that could mean it is no longer worth it:

  • Significant growth of hosted services in your infrastructure.
    Besides a significant in all regular Blueriq components that are online there would also be: Load balancers, gateways, external memory stores, etc.
    Is it worth it to include these layers and extra configuration to your infrastructure? Will the increased operating costs be worth it?
  • Overall performance might decrease.
    Though Blueriq is constantly looking too optimize and monitor general performance, it is not uncommon for request speeds to go up in any sort of failover environment.
    Using external session stores will generally not be as fast as storing state directly in server memory.
    The impact is generally well within acceptable time ranges, but do consider this when thinking about switching to a failover setup.

* Switching to newer major versions of Blueriq components might still require you to have downtime.

How to Setup Failover

Setting up Blueriq to support failover scenarios requires you to set up clusters of your Blueriq services.

You can find explanations about this over here: Runtime cluster - Blueriq Latest - Blueriq Community

The linked documentation talks about setting up clusters for Blueriq forms applications, but the same can be done in a DCM environment.

Do note that you need the modern implementation of DCM inside Blueriq that requires the case engine. (DCM2)

  • No labels