Hacker News Reader

Comment by avitzurel | Hacker News Reader

ECS is order of magnitude more complex than almost anything I had experienced with (taking out Marathon).

I found ElasticBeanstalk to me MUCH simpler for Docker based deployments. It's using ECS behind the scenes for multi-container instance.

You essentially deploy a zip with with a Dockerrun.json metadata file and it handles everything for you, including rolling deploys based on your auto scaling groups.

I never found the ECS definitions of Task and the rest really intuitive to work with.

View on HN

That's how I'm currently running our apps. There are still loads of problems and bugs on the AWS side, but that's to be expected. However, it's far from ideal in resource usage and automation (of the whole infrastructure not just individual apps). Part of my goals and probably that of the article's author was to increase resource usage. My servers are typically around 1%-10% CPU and we have a lot of apps. With a minimum of 2 decent EC2 instances per app (c4.large or better), that comes to a lot of servers with a lot of unused capacity. I could definitely see huge room for improvement and increased automation for the whole cluster (including automated deployment of supporting services) with some clustering solution based on Docker (still need to evaluate). Given my horrific experiences with AWS and AWS Beanstalk in particular, I would never run said cluster on ECS, however, due to extremely poor quality of AWS services outside of EC2 and its closed source nature.

I didn't realize ElasticBeanstalk delegated to ECS. Thanks for sharing.

ElasticBeanstalk does have some serious simplicity advantages for the type of apps it was designed for.

I'll definitely second your opinion that raw ECS can be very challenging. It's begging for some good tools to help you manage it.

I believe ElasticBeanstalk only uses ECS if you're doing multi container. If you're just deploying a single Docker image, I believe it's still using the Docker AMI on an EC2 instance.

I mentioned that in my original comment. Yeah.

What did you find complex about Marathon?

Few things

1. Mesos dependency 2. Security (Firewall) settings 3. DNS settings (You need the FQDN to resolve from each part of the system) 4. Dynamic load balancing (ELB bridge, Nginx Bridge) 5. No control over the underlying cluster, so to actually scale your app, you will need to scale your cluster first.

Those are just off the top of my head. I am using Marathon every day but I still carry a lot of pain frm the first days/weeks of using it.

Can you expand on 5.? I'm not following what you mean by 'need to scale cluster first to scale app'.

Sure.

Lets say I have a cluster of 2 machines.

I deploy my Docker container using Marathon, the constraints is that it's unique per machine.

Now, I want to scale my app to 30 containers.

Without Marathon controlling Amazon APIs and actually scaling my underlying cluster to 30 machines first, the scale will never happen.

This creates a disconnect between scaling strategies.

Reply on news.ycombinator.com