Zero downtime deployment

Overview

'Zero downtime deployment' is about changing / upgrading microservice without interruption from service's clients point of view, it should be transparent and completely online. Basically, before microservice shutting down, all of requests should be handled and results provided to the invokers (within defined timeout).

The true 'zero downtime deployment' mechanism should monitor and control the following processes and resource in the environment to be really ONLINE:

  • synchronous requests processing
  • asynchronous requests processing
  • external signal handling (ex. SIGTERM)
  • processing using custom thread pools
  • stateful requests (using data kept in the session)

We take care of all this stuff - on JLupin Platform we can perform TRUE ZERO DOWNTIME DEPLOYMENT

NATIVE microservice

When restart is going to be performed of NATIVE microservice (ex. Microservice B), the Process Manager (internal process of Main Server) tries to start another instance of the microservice (Microservice B') as show on the following picture:

Figure 1. Zero downtime deployment - NATIVE microservice - start a new instance.

After it is successfully started the traffic is redirected to the new instance (Main Server provides services through automatic interfaces so it controls all traffic coming to NATIVEs):

Figure 2. Zero downtime deployment - NATIVE microservice - switching traffic.

After this phase new requests are processed by the new instance (Microservice B'), while requests before restart are still processed by the 'old' instances. The Process Manager monitors external requests (from clients), internal requests (processed on custom thread pool), asynchronous requests coming from queues and decides to destroy the microservices after all tasks are finished or timeout has occurred, as presented on below picture:

Figure 3. Zero downtime deployment - NATIVE microservice - finish processing and destroying.

After this phase the process is finished.

NOTE that zore downtime deployment on JLupin Platform is performed on a single node, when only one instances of a microservice is run.

SERVLET microservice

In case of SERVLET microservice the zero downtime deployment process is very similar, additionally Edge Balancer is involved in this process.

Stateless SERVLET microservice

At the beginning Process Manager tries to start another instances of the microserice (ex. WebApp2), as shown on the following picture:

Figure 4. Zero downtime deployment - SERVLET microservice - start a new instance.

Just after it is started the Process Managers provides this information for Edge Balancer through INFORMATION HTTP interface to Edge Balancer (/listMicroservices URI is invoked periodically by Edge Balancer). Edge Balance switches traffic to the new instance while 'old' requests are processed by the 'old' instance:

Figure 5. Zero downtime deployment - SERVLET microservice - start a new instance.

Process Manages waits configured amount of timer while Edge Balancer discovers new microservice state and no sooner than all requests will be processed, it destroys the 'old' instances:

Figure 6. Zero downtime deployment - SERVLET microservice - finish processing and destroying.

After this phase the process is finished.

Statefull SERVLET microservice

You can perform zero downtime deployment even if session are handled on SERVLET microservices. In order to keep sessions you need to use our Http Session Repository, which is used by the old as well as the new instance of the microservice:

Figure 6. Zero downtime deployment - SERVLET microservice - statefull restart.

In that way, logged in users will not notice that restart has happened.

That's what we call TRUE ZERO DOWNTIME DEPLOYMENT :) Enjoy.