Skip to content

Instantly share code, notes, and snippets.

@rgabo
Last active December 4, 2015 17:26
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rgabo/a76c3bbd265c08bf49a7 to your computer and use it in GitHub Desktop.
Save rgabo/a76c3bbd265c08bf49a7 to your computer and use it in GitHub Desktop.
Empire vs Elastic Beanstalk

Reasons why we did not go with Elastic Beanstalk

tldr;

Elastic Beanstalk with Docker is great at having a standard way of running and scaling out web and worker applications, if you are OK with AWS abstractions and further lock-in. For instance, auto-scaling web apps using autoscaling group policies is extremely powerful, but I believe there is a lot of accidental complexity that comes with Elastic Beanstalk so we chose something that we believe is simpler and easier to understand or change.

not so tldr;

  1. AWS is great at taking an existing technology, wrapping it into AWS-specific concepts and creating a proprietary JSON/XML API around it. This is why ECS Task Definitions exist. Elastic Beanstalk goes one step further and creates yet another layer of API on top of ECS and ELB aptly called Dockerrun.aws.json v2. The format is proprietary and we preferred existing, well-known standards like simple Docker image names (sspinc/cartman-api:batteries-included), Procfile and Docker Compose files which Empire is planning to support.
  2. Elastic Beanstalk has a strong notion of a Web application and a Worker application. They are deployed separately, require separate environments/tiers and are required to communicate through SQS. Twelve-Factor apps follow a different philosophy, such as the process model for concurrency and its manifestation, the Procfile. This comes much more natural to us and it is one of our main practices. Instead of SQS, we use Redis-based background workers (Resque, Sidekiq) for lightweight tasks and Kafka for communicating between different application and services. This also results in less lock-in if we ever decided to switch away from AWS.
  3. Empire is much easier to operate within an existing VPC infrastructure where we run persistent stores that Amazon does not offer, such as MongoDB or Kafka. We use Terraform to provision our infrastructure and its very easy to provision an ECS cluster with Empire running on top of it.
  4. Empire creates internal load balancers to allow apps and services to discover each other through simple DNS resolution (i.e. http://cartman-api.sspinc.io). Empire uses a private DNS zone by default but you can expose the ELBs created by Empire in your public Route 53 DNS zone as well.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment