Hybris Type System Update on Kubernetes

Hybris provides a mechanism to rolling update the database schema without downtime. Hybris uses metadata tables that form what is called the type system to manage multiple versions of database schema. When updating your hybris application to a new version you can:

• Create a new type system (copying from current type system)
• And update the new type system

without affecting the type system used by the active application. Once this is done, we can start hybris servers with the new version of the application referencing the new type system.

Rolling Update on the Cluster

On our data centre with fixed capacity

On our current data centre where we run hybris, we have 2 limitations we need to work with:

• We have a fixed number of servers to work with. We can’t provision more easily and certainly not in an automated manner.
• We don’t have a centralised session store. User sessions are stored in the hybris server nodes where the user is connected through to from the load balancer. To ensure the user’s session is maintained across requests, we use sticky sessions and the load balancer will always direct a user to the same server they interacted with before.

So, with those limitations the process by which we currently update hybris is:

1. We drain the sessions on one of the servers to make sure customers are not directed to that server anymore.
2. We take that server off the load balancer.
3. We copy the existing type system to create a new type system.
4. Update the new type system.
5. Deploy the new version of the application referencing the new type system on that server.
6. Add the server back on the load balancer.
7. We repeat steps 1, 2, 5 and 6 for the remaining servers.

This process takes time and is hard to automate.

On Kubernetes in public cloud

When running hybris on Kubernetes in public cloud the limitation on the number of servers is gone out of the box. We also mitigated the session store issue by using a redis cluster as a centralised session store. With those 2 limitations out of the way, our strategy to run type system update on Kubernetes is:

1. Create a Job with the new version of the application (container image).
2. The Job creates a new types system and updates it.
3. Once the Job is complete, the k8s Deployment object is updated to use the new version of the application (container image). The Deployment takes care of starting Pods with the new container image and kill old Pods once the new ones are ready.

This process is entirely automated using helm. We use helm chart hooks

Chart Hooks

The Job that is responsible for creating and updating a new typesystem is defined to run as a pre-install and pre-upgrade hook.

Tweak to type system update procedure

The hybris type system uses a bunch of meta data tables; AtomicTypes, ComposedTypes, MapTypes, CollectionTypes, EnumerationValues, AttributeDescriptors etc. When we copy an existing type system to create a new one, those tables are duplicated and tables such as AtomicTypes0, ComposedTypes0, MapTypes0 etc are created. Every new type system gets their own copy of these tables. This means any downstream system that may need to reference type system tables needs to identify the version of type system tables currently in use.

To avoid this problem:

• Use a fixed reference type system, say DEFAULT or something like ‘MASTER’.
• Start by updating the reference type system.
• Then create a copy for the new version being deployed.

Most existing rolling update scenarios should be OK with this strategy. Also, any downstream systems can easily reference the type system tables for DEFAULT or MASTER which does not change.