What Are “Blue-Green” Or “Red-Black” Deployments?

Deployment
Deployment

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!

InfoSphere DataStage – Operations Manual Template

When projects transition to production, the receiving team need some transition documentation to help with knowledge transfer and to guide them while they get accustomed to operating the application and can form their own documentation.  This temple is a shell, which usually provides enough detail, with some updating, to provide a quick reference regarding the application.  Also, having a temple can be a real time-saver, as opposed to writing it from scratch.

Related References

What is BYOD?

What is BYOD?

Basically, BYOD (bring your own device) is an information technology trend toward employee-owned devices within a business, in which consumer software and hardware are being integrated into the enterprise workplace.

Benefits of BYOD

The benefits of BYOD depend upon the point of view, here is a quick list

  • Supports integrated remote work and remote workforce augmentation with requiring the acquisition of hardware and software
  • The reduced software learning curve for employees
  • Increased availability of workforce and access to the network.

Drawbacks of BYOD

  • Increased Support requirements
  • Increase Security and data exposure risk
  • Less consistent hardware and Software environment

Netezza / PureData – How to find and kill table locks

Sometimes there is a need to find and/or kill (terminate) table locks, so, that application process and user access can be restored.  To do this is relatively straight forward if you have access and the appropriate permission to the Netezza PureData server.

How to find table locks on a Netezza database

  • Log into the Netezza server
  • From the command line, navigate to Netezza directory (e.g. cd /NZ)
  • On the command line, enter show locks command

Show Locks Command (nz_show_locks) Syntax

nz_show_locks <db name> <tablename>

Example Show Locks Command (nz_show_locks)

nz_show_locks dashboard_staging stg_nz_query_history

Netezza PureData Kill Table Session locks
Netezza PureData Kill Table Session locks

How to kill table locks on a Netezza database

  • Perform find locks above
  • Then, on the command line enter kill sessions locks command

Kill Sessions Command (nzsession) Syntax

nzsession subcmd [subcmd options]

Example Kill Sessions Command (nzsession)

nzsession abort -id  523662 -force

Related References:

l

 

 

Infosphere Director Scheduler

First let us start with dispelling a common myth, The InfoSphere scheduler is not an Enterprise Scheduler application.

The scheduling service in InfoSphere leverages the operating system (OS) scheduler, in the case of Linux, this is CRON, and provides graphical User Interface, which a provides time-based capability to schedule Jobs at the Suite component level.  The Director Client scheduler can:

  • Schedule individual jobs and sequence jobs
  • Schedule Jobs/Sequencers to run:
  • Today
  • Tomorrow
  • Every
  • Next
  • Daily

How to set-up the Daily Schedule

Steps to set the Daily Schedule are below:

  1. Open the DataStage Director
  2. Once the browser is open click on Job>Add to Schedule
  3. Click “Daily” under the “Run Job” and choose the time

Related References

What is System Availability?

The term system availability, in a nutshell, describes a system operating correctly, reachable, and is available for use by consuming customer and systems.  Generally, speaking system availability is a measure used to ensure that a system and/or application is meeting it Service Level Agreement (SLA) obligations.  Any loss of service, whether planned or unplanned, is known as an outage. Downtime is the duration of an outage measured in units of time (e.g., minutes or hours).

What is a Runbook?

What is a Runbook?

What is a Runbook: a runbook is a collection of procedures, instruction, and operations used for reference (like Standard Operating procedures), which systems administrators or operations teams perform in the normal course of monitoring, controlling, and orchestrating technical systems and process.

Related Topics

What is an Enterprise Process Scheduler?

What is Runbook Automation?