1. Recreate Deployment
“Version 1
is down and version 2 is rolled out on Version 1”
Recreating deployment terminates all the pods/applications and replaces
them with the new version. This can be useful in situations where an old
and new version of the application cannot run at the same time.
Users experience some downtime because we need to stop the application
before the new version is running. The application state is entirely renewed
since they are completely replaced. if we do decide to roll back, it may
cause even more downtime.
2. Rolling Deployment (Ramped OR Incremental Updates OR
rolling updates OR rolling upgrade)
“Version 2
is slowly in phased rolled out and replacing version 1”
Rolling deployment strategy involves updating the software version in a
phased manner, typically by deploying to a subset of servers at a time. This
allows for incremental updates and minimizes the impact of any potential
issues.
If a problem is detected, it can be addressed before moving on to the next
set of servers. This strategy ensures a smoother deployment process and reduces
the risk of downtime. After replacing all instances of the older version,
it will be shut down by Ops/Dev team. After that, the new version is in charge
of all production traffic.
Rolling deployments are the default Kubernetes (k8s) cluster offering
designed to reduce downtime to the cluster. A
rolling deployment replaces pods running the old version of the application
with the new version without downtime.
3. Shadow Deployment
“Version 2
receives real-world traffic alongwith version 1 and doesn’t impact the
response.”
In this deployment strategy, developers deploy the new
version alongside the old version. However, users cannot access the new
version immediately. The latest version hides in the shadows. To test how the
new version will handle the requests when live, developers fork or copy a copy
of the old version to the shadow version.
As a result, the Ops/Dev Team should be careful to ensure that the forked
traffic does not create a duplicate live request since two versions of the same
system are running simultaneously.
It's expensive and complex to set up, and it can create serious
problems. Shadow deployment allows engineers to monitor system performance and
conduct stability tests.
4. A/B Testing
“Version 2
is released to a specific subset of users under specific condition to test and
validate.”
A/B testing is a deployment strategy that involves deploying two
different versions of the application simultaneously to different user groups. New
version is only available to a limited number of users, who are selected
according to certain conditions and configuration parameters. UI UX settings, Request
type, location, device type, and operating system can serve as parameters for
selecting these users.
By measuring the performance and
user feedback of each version, Ops/Dev teams can gather valuable data to follow
proper decision making procedures for the management. The use of
real-time statistical data can help developers make informed decisions about
their application. However, A/B testing is difficult to set up and
requires a high-end load balancer and robust infrastructure.
This strategy allows for data-driven optimization and helps ensure
that only the most effective features or changes are rolled out to all users.
5. Blue-Green / Red-Black Deployment
“Version 2
is released with Version 1, after testing passed, traffic is switched to
version 2.”
The Blue-Green / Red-Black deployment strategy involves maintaining
two identical production environments, one currently running (blue/red)
and one inactive (green/black). Stable or older versions of the
application are always blue or red, while newer versions are green or
black.
When a new version of the application is tested and ready, it is deployed
to the green/black environment. Once the new version is tested and
verified, the load balancer automatically switches traffic from the older
version to the newer one, a smooth transition is made to routing traffic from
the blue to the green/black environment, minimizing downtime and ensuring a
seamless user experience.
In addition to offering a quick update or rollout of a new application
version, this strategy has the disadvantage of being expensive since both
the new and old versions must run simultaneously. Dev/Ops team, mostly
use this method in mobile/web app development and deployment.
6. Canary Deployment
“Version 2
is released to a specific subset of users, then proceed to a full rollout on
success.”
Canary deployment strategy involves deploying a new
version of the application to a small subset of users or servers, known
as canary groups. For instance, at a certain stage in the process, 90% of
production traffic may still go through the older version while only 10% goes
through the newer one, the team responsible for deployment gradually redirects
traffic from the older version to the new one.
This allows for early testing and feedback. If the new version
performs well, it can gradually be rolled out to the rest of the users or
servers to achieve reduced risk of rollback.
Canary Deployments strategy reduces the risk of widespread issues and
allows for rapid rollbacks if necessary.
It enables better performance monitoring, faster and easier application
rollbacks, and facilitates automation in the deployment pipeline. However,
it has a slow deployment cycle, requires more time, and demands a robust
infrastructure.
This approach allows Dev/Ops Teams to evaluate the stability of the new version by using live traffic from a subset of end-users at varying levels throughout production.
