A rolling deployment is a software release strategy that updates applications incrementally to reduce downtime. It involves taking servers offline one at a time to update them while keeping other servers running to maintain service. This contrasts with traditional upgrades that take all servers offline simultaneously, disrupting service. Rolling deployments allow continuous delivery of new versions with zero downtime by replacing infrastructure components gradually rather than all at once.

1. What is rolling Upgrade and Rolling deployment Model ?

2. In a traditional software upgrade, an application servers is taken offline
while its software is updated and tested, then it is returned to service.
This can result in substantial downtime for the application -- especially if
unexpected errors or problems force a developer to revert the installation
to a previous version.
A rolling deployment is a software release strategy that staggers
deployment across multiple phases, which usually include one or more
servers performing one or more function within a server cluster. Rather
than updating all servers or tiers simultaneously, the organization installs
the updated software package on one server or subset of servers at a
time. A rolling deployment is used to reduce application downtime and
unforeseen consequences or errors in software updates.

3. In a rolling upgrade, only part of the server capacity for an application is offline at a given time.
For example, consider a three-tier application comprising front end, back end and database,
deployed with three nodes in each tier. Each of the three front-end application server nodes
receives traffic through a load balancer. In a traditional upgrade, the load balancer closes all
application traffic for the servers to go offline and update. In a rolling deployment, the
organization can take one of the nodes in each tier offline, with the load balancer configured to
direct traffic to the remaining servers still running the proven, current software version. The idle
servers receive updates and testing; the remaining online servers support user traffic.

4. Rolling updates incrementally replace your resource's Pods with
new ones, which are then scheduled on nodes with available
resources. Rolling updates are designed to update your workloads
without downtime.

5. Rolling updates allow the following actions:
•Promote an application from one environment to another (via container
image updates)
•Rollback to previous versions
•Continuous Integration and Continuous Delivery of applications with zero
downtime

6. Rolling Deployments
A rolling deployment is a deployment strategy that slowly
replaces previous versions of an application with new versions of
an application by completely replacing the infrastructure on which
the application is running. For example, in a rolling deployment in
Amazon ECS, containers running previous versions of the
application will be replaced one-by-one with containers running
new versions of the application.
A rolling deployment is generally faster than a blue/green
deployment; however, unlike a blue/green deployment, in a
rolling deployment there is no environment isolation between the
old and new application versions. This allows rolling deployments
to complete more quickly, but also increases risks and

7. When to Use
This technique can be used whenever your application
supports running multiple instances with different versions
at the same time. This is the simplest technique to
implement among the three that we will cover (the other
two are Blue-Green and Canary deployments) and should
be a good first step towards Zero Downtime Deployments.

8. Prerequisite
If your plan is to introduce this technique on a running
project, you may need to first make architectural changes to
your system:
• Make the application stateless by storing state in an
external service like a database or a key-value store.
• Support more than one instance of the application
running at the same time. You may need to introduce a
load balancer and check for potential concurrency issues.
• Introduce tests to ensure the application is backward and
forward compatible. It may be necessary to change code
to support extra parameters on database tables and
event schemas.

10. Rolling Updates
Given an application deployed to production with multiple
instances receiving traffic, a rolling update will incrementally
update or replace the instances until all of them are running the
desired version. The number of instances updated at each stage
follows a predetermined rate, and eventually reaches 100%.
In order to apply this technique, your application needs to be
able to run multiple instances at the same time, potentially with
different versions. There must be a load balancer or reverse
proxy to distribute traffic among all of them. Finally, it is
necessary to have a method to determine if an instance is
healthy and ready to serve traffic.

11. How it Works
Let’s say you have 3 instances of the application running and
serving traffic. The first step is to stop serving traffic to one of the
instances and either update the software or replace it with
another instance running the desired version. Once the instance
with the new version is created or updated, a simple test is run to
verify that the instance is healthy and can start receiving traffic.
When the test passes, the instance is added to the pool of
instances serving traffic.
When the process for one instance is complete, the same
procedure is executed for the next instance, until all of them are
running the desired version. Since there are always a few
instances running at any given time, current or new, the
application is operational all the time and no downtime is

12. Using Kubernates to Achieve this
Users expect applications to be available all the time and
deploy new versions of them several times a day. In Kubernetes
rolling updates. Rolling updates allow Deployments' update to
downtime by incrementally updating Pods instances with new
be scheduled on Nodes with available resources.
In the previous module we scaled our application to run multiple
requirement for performing updates without affecting
the maximum number of Pods that can be unavailable during
maximum number of new Pods that can be created, is one. Both
configured to either numbers or percentages (of Pods). In
versioned and any Deployment update can be reverted to a

13. THANK YOU
Like the Video and Subscribe the Channel