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!

Linux VI Command – Set Line Number

The “Set Number” command in the VI (visual instrument) text editor seems may not seem like the most useful command.  However, it is more useful than it appears.  Using the “set number” command is a visual aid, which facilitates navigation within the VI editor. 

To Enable Line Number In the VI Editor

The “set Number” command is used to make display line numbers, to enable line numbers:

  • Press the Esc key within the VI editor, if you are currently in insert or append mode.
  • Press the colon key “:”, which will appear at the lower-left corner of the screen.
  • Following the colon enter “set number” command (without quotes) and press enter.

A column of sequential line numbers will then appear at the left side of the screen. Each line number references the text located directly to the right. Now you will know exactly which line is where and be able to enter a colon and the line number you want to move to and move around the document lines with certainty.

To Disable Line Number In the VI Editor

When you are ready to turn offline numbering, again follow the preceding instructions, except this time, enter the following line at the : prompt:

  • Press the Esc key within the VI editor, if you are currently in insert or append mode.
  • Press the colon key “:”, which will appear at the lower-left corner of the screen.
  • Following the colon enter “set nonumber” command (without quotes) and press enter.

To Make The Line Number Enable When You Open VI:

Normally, vi will forget the setting you’ve chosen once you’ve left the editor. You can, however, make the “set Number” command take effect automatically whenever you use vi on a user/account, enter the “set Number” command as a line in the .exrc file in your home directory.

Related References

What is Development Operations (DevOps)?

With modern businesses continually looking for ways to streamline their operations, DevOps has become a common approach to software delivery used by development and operation teams to set up, test, deploy, and assess applications.

To help you understand more about this approach, let’s briefly discuss DevOps.

What is DevOps?

DevOps comes from two words- ‘development and operations.’ It describes a set of IT practices, which seeks to have software developers and operations team work together on the same project in a more collaborative and free-flowing way.

In simple words, this is a culture that promotes cooperation between Development and Operations teams in an organization to ensure faster production in an automated, recurring manner.

The approach aims at breaking down traditional barriers that have existed between these two important teams of the IT department in any organization. When deployed smoothly, this approach can help reduce time and friction that occur when deploying new software applications in an organization.

These efforts lead to quicker development cycles, which ultimately save money and time, and give an organization a competitive edge against its rivals with longer, more ridged development cycles.

DevOps helps to increase the speed with which an organization delivers applications and services to customers, thereby competing favorably and actively in the market.

What Is Needed for DevOps to Be Successful Executed?

For an organization to appeal to customers, it must be agile, lean, and swift to respond to dynamic demands in the market.  For this to happen, all stakeholders in the delivery process have to work together.

Development teams, which focus on designing, developing, delivering, and running the software reliably and quickly, need to work with the operations team, which is tasked with the work of identifying and resolving problems in the software as soon as possible.

By having a common approach across software developers and operation teams, an organization will be able to monitor and analyze holdups and scale as quickly as possible. This way, they will be able to deliver and deploy reliable software in a shorter time.

We hope that our simplified guide has enabled you to understand what DevOps is and why it is important in modern organizations.

Technical Debt

During the software engineering process, there are different issues which should be dealt with or else they will subject the project to unnecessary costs later. The technical debt perspective should be considered in each step of software development. For instance, when analyzing the cost of cloud approaches, you need to take into consideration the technical debt. You should as well factor the engineering aspect when making technical decisions such as choosing between cloud services vs. homegrown solutions.

What is technical debt?

Technical debt refers to the implied cost which will be incurred to do additional rework on a system after the engineering process is done. For example, engineers can choose to go for an easy option so that they can save time during the product design. The right steps which they will avoid will later need to be implemented which will mean a product has to be recalled or it will have to be fixed after it has reached the market which will cost more in terms of resources and manpower.

What are the most common types/causes technical debts?

Deliberate tech debt

In this case, engineers are aware of the step which is necessary during project implementation, but they will ignore it provided they can go for a shortcut which will save on cost and avail the product to the market. For instance, when analyzing the advantage of using the public cloud, some engineers may assume certain benefits, and later they will realize they are very necessary hence they are forced to go back and procure the system. It will lead to wastage in the company. Some engineers will not like doing the same process every now and then; they can avoid a given process only to expose the final product to flaws which will require re-engineering.

Accidental/outdated design tech debt

After designing a product or software, with time the technology will advance and render the design less effective in solving certain needs. For instance, due to advancement in technology, the tools you incorporated in a given software may end up being flawed which will make the product less effective which may necessitate re-engineering. Engineers may try their level best to come up with great designs, but advancement in technology can make their designs less effective.

Bit rot tech debt

It is a situation where a complexity develops over time. For example, a system or a component can develop unnecessary complexity due to different changes which have been incorporated over time. As engineers try to solve emerging needs, they can end up exposing the product to more complications which can be costly in the long run.

Strategies for minimizing technical debt

How to minimize deliberate tech debt

To avoid the tech debt, you need to track the backlog when engineers started the work. If you can track the backlog and identify areas where the engineers are trying to save time, you can avoid the debt.

Minimizing Accidental/outdated design tech debt

You need to refactor the subsystem every now and then so that you can identify the technical debt and fix it. For example, if the software is exposing you to unnecessary slowdowns, you need to fix the errors and make it meet industry standards.

Addressing Bit rot tech debt

Engineers should take time to understand the system they are running and clear any bad codes.

Business Linux Operating Systems

Linux
Linux

Unix and Linux are different operating systems with have some common commands. Source code for Linux is freely available to the public and Unix is not available. Linux operating system is a free/open source and Some versions of Unix are proprietary and others are a free/open source. Linux Operating system can be used for desktop systems and for servers. But the Unix is mainly used in servers, mainframes and high-end computers.

AIX is an operating system based on Unix versions from IBM. It is mainly designed for IBM’s workstations and for the server hardware platforms. And HP-UX is the operating system from HP ( Hewlett Packard ) based on Unix versions.  HP-UX and AIX are stable operating system compare with Linux. HP-UX and AIX are platform dependent and they are limited to their own hardware. But in the case of Linux, it is platform independent and can be used with any hardware. Since HP-UX and AIX are platform dependent, they are optimised for the hardware and the performance is better than Linux operating systems.  AIX is outperforming Linux from 5 to 10 percent.

Unix

AT&T Unix, started in the 1970s at the Bell Labs and newer versions of Unix have developed and some of them are listed below. In 1980, AT&T licensed Unix to third-party vendors and leading to the development of different variants. Some of them are;

  • Berkeley Unix, FreeBSD and its variants
  • Solaris from Sun Microsystem
  • HP-UX from Hewlett-Packard
  • AIX from IBM
  • MacOs from Apple
  • Microsoft’s Xenix

Unix installations are costlier since it requires some special hardware. MacOS needs apple computers, AIX needs IBM hardware and HP-UX needs HP hardware etc.

Linux

Linux is a free and open source operating system based on Unix. Linux kernel was first developed by Linus Torvalds in 1991. Linux was originally developed for personal computers but nowadays it is using personal computers as well as in server systems. Since it is very flexible, it can be installed in any hardware systems. Linux operating system is available for mobile phones, tablets, video game consoles, mainframes and supercomputers. Some of the best distros for small business are;

  • Centos
  • ClearOS
  • OpenSUSE
  • IPFire
  • Ubuntu
  • Manjaro
  • Slackware

Linux Vs Unix

Linux Unix
The Source Code of Linux is freely available to its Users. The Source Code of Unix is not available for the general public.
Linux primarily uses Graphical User Interface with an optional Command Line Interface. Unix primarily uses Command Line Interface.
Linux OS is portable and can be executed in different Hard Drives. Unix is not portable.
Linux is very flexible and can be installed on most of the Home Based Pcs. Unix has a rigid requirement of the Hardware. Hence, cannot be installed on every other machine.
Linux is mainly used in Home Based PC, Mobile Phones, Desktops, etc. Unix is mainly used in Server Systems, Mainframes and High-End Computers.
Different Versions of Linux are: Ubuntu, Debian, OpenSuse, Redhat, Solaris, etc. Different Versions of Unix are: AIS, HP-UX, BSD, Iris, etc.
Linux Installation is economical and doesn’t require much specific and high-end hardware. Unix Installation is comparatively costlier as it requires more specific hardware circuitry.
The Filesystems supported by Linux are as follows: xfs, ramfs, nfs, vfat, cramfsm ext3, ext4, ext2, ext1, ufs, autofs, devpts, ntfs The Filesystems supported by Unix are as follows: zfs, js, hfx, gps, xfs, vxfs.
Linux is developed by an active Linux Community worldwide. Unix is developed by AT&T Developers.

Hardware architecture

Most commercial versions of UNIX distributions are coded for specific hardware. Like HP-UX for PA-RISC (Hewlett-Packard) and Itanium machines (Intel) and AIX is for Power processors ( IBM ). Since these distributions are limited, the developers can optimise their code for these architectures to get maximum utilisation of resources.  Since it uses proprietary hardware, Unix distributions are not cost effective.

  • HP-UX needs HP or Intel hardware
  • AIX needs IBM Hardware

Linux operating system is not dependent on the hardware, so it can be installed in any of the server systems which have a processor. Since the developers cannot assume the hardware architecture and they need to prepare the code for some general hardware specifications and that’s why Linux operating system has less performance than the commercial Unix variants.

  • Linux is open to all hardware

Licensing

GNU General Public License (GPL), is a form of copyleft and is used for the Linux kernel and many of the components from the GNU Project. Free software projects, although developed through collaboration, are often produced independently of each other. AIX and HP-UX are using proprietary licenses.

HP-UX

Developer Hewlett-Packard Enterprise
Written in C
OS family Unix (System V)
Initial release 1982; 36 years ago
Kernel type Monolithic with dynamically loadable modules
License Proprietary

 

IBM AIX

Developer IBM
Written in C
OS family Unix
Initial release 1986; 32 years ago
Kernel type Monolithic with dynamically loadable modules
License Proprietary

 

Linux

Developer Community, Linus Torvalds
Written in Primarily C and assembly
OS family Unix-like
Initial release September 17, 1991; 26 years ago
Kernel type Monolithic (Linux kernel)
License GPLv2[7] and other free and open-source licenses (the name “Linux” is a trademark[b])

 

Softwares and Tools

Softwares and tools in Linux are general to all hardware. But in the case of Unix, separate tools and software which leverage to get the maximum performance. So the performance of the systems is higher than the Linux operating system by comparing the hardware configuration. Unix has good performance than Linux systems. While considering the cost estimation, Linux will get more votes.

System Management Interface Tool ( SMIT ) with AIX is the tools used for package management, System Administration Manager (SAM) on HP-UX. Linux operating system uses rpm or dpkg etc. based on the variants.

Software Installation and Patch Management

R H Linux

HP-UX

AIX

Install rpm -i file swinstall –s depot software installp –a [-c] FileSet
Update rpm -U/F file swinstall –s depot software installp –a FileSet
List rpm -q swlist –l product lslpp –L all
Remove rpm -e swremove software installp –u FileSet
Patches rpm -u swinstall installp
List Patches rpm -q -a swlist –l product lslpp –L all
Patch check up2date/yum security_patch_check compare_report

File system

While talking about the file systems, Linux scores more than the other Unix versions. Unix supports two or three file systems locally. But Linux supports almost all the file systems available on any operating system.

 

System Filesystem
AIX jfs, gpfs
HP-UX hfs, vxfs

Kernel

The kernel is the core of the operating system and the source code of the kernel are not freely available for the commercial versions of Unix. For the Linux operating system, the users can check and verify the code and even modify it if required.

Support

The commercial versions of Unix come with a license cost. Since these operating systems are purchased, the vendor will provide technical support to the end users to the smooth running of the operating systems.

In the case of the Linux operating system, we need to use the open source forums and community for getting support from the users and developers around the world or hire some freelancers for fixing the issues.

Related References

What is Source Control?

Acronyms, Abbreviations, Terms, And Definitions
Acronyms, Abbreviations, Terms, And Definitions

Source Control is an Information technology environment management system for storing, tracking and managing changes to software. This is commonly done through a process of creating branches (copies for safely creating new features) off of the stable master version of the software, then merging stable feature branches back into the master version. This is also known as version control or revision control.

Netezza / PureData – How To Get A List Of When A Store Procedure Was Last Changed Or Created

Netezza / Puredata - SQL (Structured Query Language)
Netezza / Puredata – SQL (Structured Query Language)

In the continuing journey to track down impacted objects and to determine when the code in a database was last changed or added, here is another quick SQL, which can be used in Aginity Workbench for Netezza to retrieve a list of when Store Procedures were last updated or were created.

SQL List of When A Stored Procedure was Last Changed or Created

select t.database — Database
, t.OWNER — Object Owner
, t.PROCEDURE — Procedure Name
, o.objmodified — The Last Modified Datetime
, o.objcreated — Created Datetime

from _V_OBJECT o
, _v_procedure t
where
o.objid = t.objid
and t.DATABASE = ‘<<Database Name>>
order by o.objmodified Desc, o.objcreated Desc;

 

Related References