In modern cloud environments where everything runs in containers, you can scale your application by simply starting more of your application containers. So, scale-up is no problem. But what about scaling down? Cloud infrastructure is not free of charge and comes with a price tag. So, to save money you have to scale down the containers as soon as possible. But what happens to the user sessions that were running on the containers you would like to stop? Is all the work lost?
- Store the user session data on the client (web browser) instead of the server (container).
- Replicate the session data, so that they are available on all containers.
- Store the session data in a memory database that runs in its containers.
All those solutions need to serialize/de-serialize the session data to send it over the wire either to the client or the other application containers or memory database. This comes with a performance impact depending on the size of your session data.
Currently, Axon Ivy does not support any of the above methods. We are using sticky sessions so that a client always works with the same container where the client's session data is held in memory. However, if the container is stopped not all the work of the user is lost. Only the data the user has entered in the current task is lost and must be re-entered again. Once a task is done the data that was entered by the user is stored in the system database. Moreover, if you use an external database or Axon Ivy's business data the data may be saved even earlier.
In this year's code camp I tried to build a prototype that stores the session data not only in the memory of the container but also in the Redis memory database. By doing so no sticky sessions are necessary and you can scale down without losing session data.
The main target of the prototype was to find out how hard it is to implement storing Axon Ivy sessions in a memory database and what restrictions this brings to Axon Ivy projects.
I implemented a first raw shaky prototype where the session data was stored in the Redis memory database. Along the way, I found several classes in the Axon Ivy core that need to implement the Serializable interface so that they can be stored in Redis. Also, Axon Ivy needs to serialize HTML Dialog data objects, process data objects, sessions, and view beans.
This means that not only the Axon Ivy core must be refactored to support this feature but also the Dev-Workflow-UI, Engine-Cockpit and Portal need major refactoring.
Also, your Axon Ivy Project needs to be refactored. Mainly, all your session and view beans must implement the Serializable interfaces and be aware that they can be serialized. Moreover, process and HTML Dialog data fields must be serializable if they are pure Java types (e.g., not Axon Ivy data classes).
There is a long way before us that takes quite some effort before Axon Ivy can replicate sessions.
Also, I did not measure the performance we lose. And finally, also your projects need to be adapted to support replicated sessions.
Future will tell if we will build in session replication and if so in which version. Stay tuned.