Elastic Beanstalk

Introduction

• Providing application code / Git Repo, scalable application / RDS to deploy onto AWS.

• Managed service:

  • Instance configuration / OS is handled by Beanstalk

  • Deployment strategy is configurable but performed by Elastic Beanstalk

• Good to re-platform your application from on-premise to the cloud

• Only pay for the instances used

Feature

• Supports:

  • Go

  • Java SE / Tomcat

  • .Net on Windows Server with IIS

  • Node.js

  • PHP

  • Python

  • Ruby

  • Packer Builder

  • Docker (Single container / multiconainer / preconfigured )

  • Can write your custom plaform (advanced)

• Architecture model:

  • Single Instance: good for dev

  • LB + ASG: good for production or pre-production apps

  • ASG only: good for non-web apps in production

• Deployment policy:

  • All at once

  • Rolling (reduce capacity then fill back with new service)

    • Deploy the new version in batches. Each batch is taken out of service during the deployment phase, reducing your environment's capacity by the number of instances in a batch.

  • Rolling with additional batch (provision new service then terminate old one)

    • Deploy the new version in batches, but first launch a new batch of instances to ensure full capacity during the deployment process.

  • Immutable

    • Deploy the new version to a fresh group of instances by performing an immutable update.

  • Traffic splitting

    • Deploy the new version to a fresh group of instances and temporarily split incoming client traffic between the existing application version and the new one.

• Replacement Options for Configuration changes:

  • Rolling

    • prevents downtime, applies changes in batches, keeping a minimum number of instances running and serving traffic at all times.

  • Immutable

    • Launches a temporary ASG outside of your environment with a separate set of instances running with the new configuration.

    • Then places the new instances behind your load balancer. Old and new instances both serve traffic until the new instances pass health checks.

    • Then moves the new instances into your ASG and terminates the temporary group and old instances.

  • Disabled (like all at once)

    • Makes no attempt to avoid downtime. It terminates old instances and replaces them with new ones.

• Scenarios

  • Decoupling Web Server, Woker Servers with SQS

    • If a service contains web tier and worker tier, can decouple them by SQS.

  • Blue / Green Deployment

    • Create a new "stage" environment for deploying v2 there

    • Route swapping options:

      • Utilize Route53 with weighted policies

      • Use "swap URLs" (DNS swap) when done with the environmrnt validation