Deployment

Infrastructure as Code

Allows infrastructure to be managed in the same way as software. (In a text file with Deployment command language)

• Version Control can be applied to it.

Examples

• CloudFormation Templates (JSON, YAML).

• CloudFormation Designer.

  • Enables visual design the needed architecture on screen.

  • And auto generates an CloudFormation Template.

Example - with OpsWork

Check out in Deployment Section.

Deployment Options

There are many deployment options in AWS.

You can use them individually or you can manage them and automate them across the entire lifecycle.

Manually

CodeCommit

• You can manage the code with CodeCommit, which is a repository for the code that run Git.

• Very similar to GitHub.

• Updates on the repository can trigger Build Jobs which can build the code automatically.

  • With CodeBuild.

CodeBuild

• Used to build applications from CodeCommit repositories.

• Also used to implement testing to make sure that not only the code compiles but also works as intended.

• Once it's ready for production you can pass either:

  • Manually pass to CodeDeploy.

    • And after set CloudFormation and CloudWatch.

  • Or use Deployment or Deployment, so AWS will automatically manage Provision AND Monitor.

CodeDeploy

• Used to get the code ready for deployment and pass it to Deployment.

• It is also possible to use Deployment or Deployment instead, to manage provision and monitor of the resources.

CloudFormation

• Will provision those compute resourses.

• Once all it is all up and running, we can implement CloudWatch.

CloudWatch

• That will continually monitor those deployment resources.

Automatically

With CodePipeline

• Deployment will manage the entire process automatically.

Deployment with Containers

With Elastic Container Service (ECS)

• Check more info about it Deployment.

With Elastic Kubernetes Service (EKS)

• Check more info about it Deployment.

Deployment Strategies

• There are a number of different strategies when doing deployments.

All at Once Deployments

• Gets all of our instances and update them at once. (At the same time)

• While they update the Elastic Load Balancer won't be able to send traffic to any of the instances.

  • So there will be DOWNTIME.

• No availability during deployment process if no new resources are created.

  • Availability can be maintained if resources are doubled (disposable resources).

    1. You copy the environment, and tell Route 53 to redirect traffic to this new copied environment.

    2. The original environment will be down while updating.

    3. After the update finished, revert routes in Route 53 and dispose the resources. (deleting the copied environment)

In-Place Deployments

• Allow us to simply update each instance one-by-one. (Individually)

• While each one update, the Elastic Load Balancer won't send traffic to the updating instance.

  • So the overall capacity will be REDUCED.

  • This can affect availability in peak access periods.

• No new resources are created.

Rolling Deployments

• Similar to In-Place, except that we add an additional instance to cover that instance that is being updated.

• Overall capacity is maintained and no downtime will happen.

• New resources are created but, only for the updating instance.

Blue/Green Deployment

• You will always have 2 identical environments, (similar to the solution for downtime in All at Once Deployments).

  • One is the Blue:

    • Which is the one actually running and receiving traffic from Route 53.

    • The Production environment.

  • The other is the Green:

    • Which is the one receiving updates and being tested for production.

    • The Development environment.

• When the Green is ready and fully updated, it becomes the new Blue and traffic is redirected to it.

• Then the old Blue becomes Green, and will be used for future updates. (And the cycle restarts)

• If problems were detected with the update (e.g bad code), you can simply redirect the traffic back to the old environment. (Rollback)

• Will have minimal to none downtime.

• BUT this will require DOUBLE the resources ALL THE TIME.

Canary Deployment

• Is a two-stage Blue/Green deployment.

  • Where it differs is that instead directing 100% of the traffic to the new environment after the update, you tell Route 53 to direct half of the traffic to the Green updated environment and keep half the traffic in the Blue.

  • Once we are satisfied with the update, then put 100% of traffic to the Green, and make the shift Green -> Blue and restart the cycle.

• This method will have reduced risks after updating BUT will have increased deployment time.

Linear Deployment

• Is an incremental Blue/Green deployment.

  • Instead of going 50/50 like the Canary, we start sending only 10% to the Green and keeping 90% in the Blue.

  • In the next stage, we increase 10% -> 20% to the Green.

  • And keep increasing traffic to the Green in each stage until all the traffic goes to Green, and switch Green -> Blue.

• This method minimizes the spread of problems to users.

• Will have increased deployment time.