From the course: AWS Certified Developer - Associate (DVA-C02) Cert Prep

AWS CodeDeploy in-place vs. blue-green deployment - Amazon Web Services (AWS) Tutorial

From the course: AWS Certified Developer - Associate (DVA-C02) Cert Prep

Start my 1-month free trial Buy for my team

AWS CodeDeploy in-place vs. blue-green deployment

“

- [Instructor] In CodeDeploy, you can either use an in-place or a blue/green deployment option for releasing code versions to your production environments. In this section, we will learn about their differences and their pros and cons so you can make a better decision when choosing a strategy for your deployment process. First, let's talk about how in-place deployment works. Say you have a web application running across EC2 instances inside a deployment group, and you want to update its user interface to make it more responsive. After developing the code for the new UI, the next thing you want to do is to archive the new application code along with an AppSpec file into a deployable content, which can be a ZIP or a TAR file. Take note that just like the buildspec, the YAML file, an AppSpec file must be located at the root level of your application folder. After building the archive, upload it to a repository that CodeDeploy supports. You can store the archive file to Amazon S3 and GitHub or Bitbucket. However, only EC2 and on-premises deployments can use GitHub and Bitbucket as repositories. When you deploy these new updates using in-place deployments, CodeDeploy will stop and uninstall the previous application version from your instances. What happens next is that CodeDeploy will pull the latest code version from the repository that you selected and install it to your EC2 instances. CodeDeploy will restart the application back into service once the deployment is completed. The disadvantage of an in-place deployment is that your application will experience an outage at the period of time during the deployment process. It also has a slower rollback compared to a blue-green deployment because it would take time to revert back the changes made to all instances. However, there is a way on how you can get around these disadvantages. And that is by modifying your deployment configuration. And by the way, what I just described here is an example of an all-at-once deployment configuration, which is also the default configuration for in-place deployments. We will discuss more about deployment configurations later on. For now, let's just focus on in-place and blue/green deployments. The biggest advantage of an in-place deployment is that it's cheaper to implement since you're only maintaining a single environment. Also, take note that in-place deployment is only available for deployments on EC2 and on-premises compute platform. Now let's go to blue/green deployments. In a blue/green deployment, you maintain two separate environments that have their own compute and network resources. Usually, each environment contains a load balancer that targets a group of computing resources. The blue environment refers to the active environment to which current user traffic is directed. The green environment is where the latest application revision is deployed. Once the new version has been successfully deployed to the green environment, the web traffic will be shifted away from the blue environment to the green environment, which now contains the updated version of your application. This cutover is done by using Route 53 to redirect the DNS records of the blue environment's load balancer to the green's load balancer. Once all user traffic is served by the green environment, the previous blue environment now becomes the green environment, and the current environment where the new version is installed becomes the new blue environment. The biggest advantage of a blue/green deployment is that switching to a new application version won't involve any downtime since you're just redirecting traffic, unlike in in-place deployments. The second advantage is that rolling back to the previous environment in case something goes wrong is much smoother because the switching's done at the network level. Also, since the blue and green environments are isolated from each other, you can perform tests on the green environments without affecting the operation of the blue environments. The obvious downside of a blue-green deployment is its expensive implementation cost that comes from running two environments at the same time.

Contents