Adopting DevOps: Understanding Blue/Green Deployments

Adopting DevOps: Understanding Blue/Green Deployments

Of all the aspects related to getting new code to production, deployment seems to be the most heinous beast of them all. The deployment stage is where new code goes to grow old in age, sometimes never getting released at all. After all, the deployment stage is where "sh*t gets real." There are a ton of things that need to happen in tandem to deliver new code to users.

There are many different ways to get your code to production. It's the duty of your organization's DevOps engineers to decide which method is best for your specific use case. Today, we're to cover one of the more sophisticated methods of deploying code: the Blue/Green Deployment.

What is a Blue/Green Deployment?

The Blue/Green Deployment is a deployment methodology that involves running two exactly similar production environments. These environments are created using "Infrastructure As Code" with popular tools like AWS CloudFormation, HashiCorp Terraform, among others. These tools enable DevOps engineers to describe their environments with code (typically JSON or YAML), so they're not burdened with trying to configure environments manually. Imagine how difficult it would be for an engineer at a large organization to quickly configure a new environment, making sure they get every detail correct. Impossible!

The purpose of the Blue/Green Deployment is to reduce the amount of time it takes to deploy code to a production environment, all the while minimizing any potential for downtime for users. It also allows engineering teams the ability to quickly revert a deployment should an issue arise.

How does it work?

Say our team has a production environment currently sitting at Version 1.4. Version 1.5 has just been promoted from its prior stages and is ready to assume the responsibilities of our organization's Production needs.

Version 1.5 of our code will be deployed to an exactly similar environment through our use of Infrastructure As Code (Remember that from before? Good.). This environment will exist next door to our current production version (1.4) but won't receive any traffic from our DNS or load balancers.

Once Version 1.5 is up and running in our exactly similar environment, we're able to run our tests and evaluate its "production-worthiness". If we find an issue with the deployment or the updates don't pass the careful tests of our QA team, we spin down the environment, fix the issue, and repeat. If we get the "OK" from our product team, we're ready to hand Version 1.5 its crown. It's the new ruler of the Production kingdom.

What happens next?

Now that Version 1.5 is ready to roll, it's nothing more than a matter of getting the new environment into the hands of our users. What's the best way to go about doing this?

The simplest way to get traffic flowing to a new environment is to update your DNS routes to point to the new environment. But if you've spent a single day in the software world, you know that switching DNS information is clunky and can take several days to fully populate. This is unacceptable!

This is where Load Balancers will be your best friend. If you set up your Infrastructure As Code (Remember that from before? Good.) correctly, you can update your new environment to be a child of your infrastructure's load balancer. Then it's just a matter of telling the Load Balancer to send traffic to Version 1.5 instead of Version 1.4. This can happen instantaneously, as opposed to our DNS option.

Considerations when using a Blue/Green Deployment

There are a few critical pieces to the Blue/Green Deployment puzzle for your DevOps team to consider.

Firstly, everything should be automated. I've stressed this point throughout the article. In no way should your infrastructure rely on manual input by your engineers. IN NO WAY. Use the concept of Infrastructure As Code to make sure everything stays exactly similar.

Secondly, make sure you're only using a single production database. It seems like common sense, I know. But it's important. Use database migrations to manage your schema with software releases. If you encounter any issues, you simply roll back and fix the issue.

Lastly, and perhaps most importantly, is that your software should not be persisting state to the server. Did you catch that? Do not persist state to the server. When you switch between Version 1.4 of your environment and Version 1.5, any state will be lost for your users. And that can spell trouble for a modern application. Make sure you're leveraging services like Amazon S3, Redis, or Memcached to control things like cookies or tokens. This will allow you to switch back and forth between environments with no troubles.

In Summary...

Deployments are hard, okay? We get it. But there are ways your team can make their lives way, way easier. Consider using Blue/Green Deployments in your software lifecycle to speed up releases and reduce downtime.

Shameless plug: organizations of all sizes use North Labs as their team's AWS DevOps specialists.

Collin Graves

We help companies advance their cloud data analytics mission with fractional data teams that cost less than one full-time hire. | USAF Veteran

6 年

Thoughts on Blue/Green Deployments? Let me know!

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了