Chances are you’ve
participated in changing or upgrading software or application. While the idea
is to push new features to customers or end-users, there have been significant
changes over the years in how dev teams build and deliver applications. This
shift has been necessitated by the growing need for agility in businesses.
Today, enterprises are
pushing their teams to deliver new product features, more often, more rapidly, and
with minimal interruptions to the end-user experience. Ultimately, this has led
to Shorter deployment cycles that translates to:
- Reduced time-to-market
- More updates
- Quicker customer to
the production team, leading to faster fixes on bugs and faster iterations on
- More value to
customers within shorter times
- More coordination
between the development, test, and release teams.
But what has changed
over the years, really? In this article, we’ll talk about the shift in
deployment strategies from traditional deployment approaches to the newer and
more agile deployment methods and the pros and cons of each of the strategy.
Let’s dive in, shall
Deployment Strategies. The “one-and-done” Approach.
strategy required dev teams to update large parts of an application and
sometimes the entire application in one swoop. The implementation happened in
one instance, and all users moved to the newer system immediately on a rollout.
This deployment model
required businesses to conduct extensive and sometimes difficult development
and testing of the monolithic systems before releasing the final application to
on-site installations, the end-users relied on plug-and-install to get the
latest versions of an application. Since the new application updates were
delivered as a whole new package, the user’s hardware and infrastructure had to
be compatible with the software or system for it to run smoothly. Also, the
end-user needed hours of training on critical updates and how to make use of
of Traditional Deployment Strategies
Low operational costs:
Traditional deployment models had lower operating expenses since all
departments were replaced on a single day. Also, since most of the applications
were vendor-packaged solutions like desktop apps or non-production systems,
there were minimal maintenance expenses needed after installation.
requirements. This means that teams would just start coding without tons of
requirements and specification documents.
They worked well for
small projects with small teams.
Faster Return on
Investment since the changes occurred site-wide for all user hence better
returns across the departments
of Traditional Deployments
strategies presented myriad challenges, including:
- It was extremely risky
to roll back to the older version in case of severe bugs and errors.
- Potentially expensive:
Since this model had no formal planning, no formal leadership, or even standard
coding practices, the model was prone to costly mistakes down the line that
would cost the enterprise money, reputation, and even loss of customers.
- It needed a lot of
time and manpower to test.
- It was too basic for
modular, complex projects.
- It needed separate
teams of developers, testers, and operations. Such huge teams were slow and
- High user disruptions
and major downtimes. Due to the roll-over, organizations would experience a
“catch-up” period that had low productivity effect as users tried to adapt to
the new system.
As seen above,
traditional deployment methodologies were rigorous and sometimes had a lot of
repetitive tasks that consumed staggering amounts of coding hours and resources
that could otherwise have been used in working on core application features.
This kind of deployment approach would not just cut it in today’s fast-paced
economies where enterprises are looking for lean, highly-effective teams that
can quickly deliver high-quality apps to the market.
The solution was to
come up with deployment strategies that allowed enterprises to release and
update different components frequently and seamlessly. These deployments
sometimes happen very fast to meet the increasing end-user needs. For instance,
a mobile app can have several deployments within a day for optimum UX needs.
This is made possible with the adoption of more agile approaches such as
Blue-Green or Red-Black deployments.
Is “Blue-Green” Vs. “Red-Black” Deployments?
Blue-green and red-black
deployments are fail-safe, immutable deployment processes for cloud-native
applications and virtualized or containerized services — ideally,
Blue-Green” Vs. “Red-Black” Deployments are identical and are
designed to reduce application downtime and minimize risks by running 2
identical production environments.
Unlike the traditional
approach where engineers fix the failed features by deploying an older stable
version of the application, the Blue-green or the red-black deployment approach
is super-agile, more scalable, and is highly automated so that bugs and updates
are done seamlessly.
“Blue-Green” Vs. “Red-Black”. What’s
Both Blue-Green and
Red-Black deployments represent similar concepts in the sense that they both
apply to the automatable cloud or containerized services such as a web service
or SaaS Systems. Ideally, once the dev team has made an update or an upgrade,
the release team will create two mirror production environments with identical
sets of hardware and route traffic to one of the environments while they test
the other idle environment.
what is the difference between the two?
The only difference
lies in the amount of traffic routed to the live and idle environments.
redeployment, the new release is deployed to the red-environment while
maintaining the traffic to the black-environment. All smoke test for
functionality and performance can be run on the black environment without
affecting how the end-user is using the system. When the new updates have been
confirmed to be working properly, and the black version is fully operational,
the traffic is then moved to the new environment by simply changing the router
configuration from red to black. This ensures near-zero downtime with the
This is similar to
blue-green deployments. Only that, with blue/green deployments, it is possible
for both environments to get requests at the same time temporarily through
load-balancing, unlike the red/black deployment, where only one version can get
traffic at any given time. This means that in blue-green deployments,
enterprises can release the new version of the application to a select group of
users to test and give feedback before the system goes live for all users.
“Blue-Green” Or “Red-Black” Deployments
You can roll back the
traffic to the still-operating environment seamlessly and with near-zero user
- Reduced downtime
- Allows teams to test
their disaster recovery procedures in a live production environment
- Less Risky since test
teams can run full regression testing before releasing the new versions
- Since the two codes
are already loaded on the mirror environments and traffic to the live site is
unaffected, test and release teams have no time pressures to push the release
of the new code.
Blue-Green and Red-Black Deployments
- It requires
infrastructure to carry out Blue-Green deployments.
- It can lead to
significant downtime if you’re running hybrid microservice apps and some
traditional apps together.
- Database dependent:
Database migrations are sometimes tricky and would need to be migrated
alongside the app deployment
- It is difficult to run
at large scale
There you have it!