Skip to content

Instantly share code, notes, and snippets.

@joffotron
Last active December 21, 2018 00:09
Show Gist options
  • Save joffotron/db362287141d2130d56d60aecf245ed2 to your computer and use it in GitHub Desktop.
Save joffotron/db362287141d2130d56d60aecf245ed2 to your computer and use it in GitHub Desktop.

Quick thoughts:

  • Easy to get "stuck" deployments or config changes, that leave the app/stack in an non-abortable, non-recoverable state for long periods of time. Like, an hour

  • Deployments are very slow.

  • The case when config changes (e.g. bumping the stack "version") needs you to build a new stack, failover DNS to that, is slow and pretty terrible

  • The way it uses Cloudformation is weird in that it creates a second, oddly named Cfn stack. It's just.. weird, and confusing for new players

  • .ebextensions must be idempotent - easy trap for beginners (who are the target audience)

    • If you're not careful, you can leave your system in an indeterminate state
    • Failures in those scripts can break your deployment
    • The syntax is awful, and poorly documented
  • Security

    • (my experience is mainly using the ruby stack). Passenger + nginx are old versions:
    • Our pentesters found this, and noted several CVEs that might apply.
    • I don't know if AWS are backporting security fixes into those versions or not? Very unclear, and makes me nervous
    • The built in package patching scheme is to run once a week. For a machine, on the internet, in 2018. Seems bad
    • To fix this you have to write an ebextension to run yum-cron etc. Not something a beginner would do
  • It's expensive once you get past a single "thing".

    • I'm going to be able to save $40k a year on costs by consolodating our stuff down onto ECS or something similar
  • It's the default choice for "I want a webapp" on the console homepage. I would argue that something like Fargate would be a better choice these days

  • It hasn't change or improved at all in the 4 years or so when I first evaulated (and rejected) it. It feels very unloved from an AWS perspective. (this may not be correct, but it feels that way)

  • There are two different "docker" options for Beanstalk, a "single app" and a "multi app" approach.

    • They have almost nothing in common with each other, the deployment file syntax is completely different, and the docs are confusing
    • The multi-app one is nowhere near as good as ECS, and anyone looking at that would be better off just going straight to that instead
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment