Bert Swope
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 features
- 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 we?
Traditional Deployment Strategies. The “one-and-done” Approach.
Classic deployments 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 the market.
Characterized by 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 the deliverable.
Pros 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.
No planning 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
Cons of Traditional Deployments
Traditional deployment 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 lethargic.
- 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.
What 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 the difference?
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.
So, what is the difference between the two?
The only difference lies in the amount of traffic routed to the live and idle environments.
In Red-Black 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 latest release.
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.
Pros Of “Blue-Green” Or “Red-Black” Deployments
You can roll back the traffic to the still-operating environment seamlessly and with near-zero user disruptions.
- 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.
Cons of 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!
