Zero downtime deployments & data migrations - tarunchhabra/parakalo GitHub Wiki

Zero downtime is the property of your software deployment pipeline by which you release a new version of your software to your users without disrupting their current activities—or at least minimizing the extent of potential disruptions.

https://www.exoscale.com/syslog/kubernetes-zero-downtime-deployment/

In a deployment pipeline, zero downtime is the feature that will enable you to eliminate the maintenance window. Instead of having a strict timeframe with in which you can deploy your releases, you might have the freedom to deploy new releases of software at any time of the day.

With zero downtime, you will have the ability to deploy multiple times per day, possibly with increasingly smaller batches of change.

Why Microservices and Zero downtime deployments ?

In a distributed system with multiple moving parts, you can’t allow the unavailability caused by a deployment in a single artifact to bring down your entire system. You’re not allowed to have downtime for this reason.

Old deployment way - undeploy your application’s current version and then deploy the new version to your running system.This will result in an undesirable amount of downtime.

First, we need to add a Load Balancer. Eg: Nginx

After you have modified your architecture to accommodate the proxy or load balancer, you can upgrade it so that you can create blue/green deployments of your software releases

Second, Requirement- Blue Green Deployment

Blue/green deployment is a very interesting deployment architecture that consists of two different releases of your application running

Zero downtime data migrations

Book- Read on local

https://developers.redhat.com/videos/youtube/3mj6Ni7sRN4

Database migrations need to be a part of our software deployment process. Database migrations are code, and they must be treated as such. They need to be committed in the same code repository as your application code. They must be versioned along with your application code.

Tool - Flyway It tie the execution of the schema evolution to your software deployment pipeline so that you can assure that the tool will be run only once for each deployment, and that your application will have the required schema already upgraded when it starts up.

https://www.baeldung.com/database-migrations-with-flyway

https://www.baeldung.com/spring-boot-flyway-repair

Flyway provide locking mechanisms to prevent multiple concurrent processes updating the database. We still prefer to not tie database migrations to application startup: we want to stay on the safe side.

From a relational database perspective, zero downtime on a blue/green deployment requires that both your new and old schemas’ versions continue to work correctly at the same time

Schema versions between consecutive releases must be mutually compatible. It also means that we can’t create database migrations that are destructive. Destructive here means that we can’t afford to lose any data, so we can’t issue any statement that can potentially cause the loss of data.

Instead of just issuing a single statement to achieve a single column rename, we’ll need to get used to breaking these big changes into multiple smaller changes.

To achieve our goal the trick is to split the schema update into a series of small side-by-side compatible schema updates. Additionally, the application needs to be updated in increments, such that a new app version is able to cope with the current schema update and the next one.

You might argue that if there’s any kind of locking, it’s not real “zero” downtime. However the true purpose of zero downtime is to achieve zero disruption to our users. Your business scenario will dictate the maximum period of time that you can allow for database locking.