4 ms·

What this post doesn't explain well is the benefit of using ECS rather than just uploading a docker image to an EC2 instance and running it.

sudhirj 9y ago
Even the smallest EC2 images can run multiple containers if your containers are small enough, and either way it makes sense to add a level of abstraction over your pool of EC2 instances - i.e. treat them as pool as opposed a set of discrete blocks. ECS lets you specify exactly what resources each container needs, and then lets you make your pool shrink or grow as necessary. The pool can also be a heterogenous mixture of instance types, even a combination of on premise (?) ones. And could also be spot instances, which are way cheaper. Could also be whichever spot instance types happen to be cheapest at the moment. So yeah, being able to pool your EC2 instances is useful.
- matwood 9y ago
  > And could also be spot instances, which are way cheaper. This what we are currently using ECS for. Keep a set of on demand instances to handle a base load and scale out on spots. Any compute that is not time dependent is on spots 100%. We have been using AWS for a long time, and wrote/still have a system to scale out instances with AMIs. This system is heavy weight though because multiple AMIs cannot share an instance. Kubs is our next step.
NathanKP 9y ago
Using a container orchestration system gives you far more resilience than just running a docker image on an EC2 instance. When you run a docker image on an EC2 instance if that docker image crashes what will restart it? What if the EC2 instance itself fails? With ECS you give the container orchestrator an intent: "Run X copies of this container at all times, associated with this load balancer" Then you give the container orchestrator a place to launch stuff: either a cluster of EC2 instances, or AWS Fargate. Then the orchestrator continuously validates the state of your deployment and relaunches or moves containers as needed to serve your intent. You can even run spot instances to get up to 80% savings on your AWS bill, and if you get outbid on the spot market the container orchestration layer will move your containers to another machine. That in a nutshell is the benefit: the orchestrator lives outside of your instance and prevents the instance from being a failure point in your system, by separating your intent to run an application from the underlying resources that actually run it.

sudhirj 9y ago

Even the smallest EC2 images can run multiple containers if your containers are small enough, and either way it makes sense to add a level of abstraction over your pool of EC2 instances - i.e. treat them as pool as opposed a set of discrete blocks. ECS lets you specify exactly what resources each container needs, and then lets you make your pool shrink or grow as necessary. The pool can also be a heterogenous mixture of instance types, even a combination of on premise (?) ones. And could also be spot instances, which are way cheaper. Could also be whichever spot instance types happen to be cheapest at the moment. So yeah, being able to pool your EC2 instances is useful.

matwood 9y ago
> And could also be spot instances, which are way cheaper. This what we are currently using ECS for. Keep a set of on demand instances to handle a base load and scale out on spots. Any compute that is not time dependent is on spots 100%. We have been using AWS for a long time, and wrote/still have a system to scale out instances with AMIs. This system is heavy weight though because multiple AMIs cannot share an instance. Kubs is our next step.

NathanKP 9y ago

Using a container orchestration system gives you far more resilience than just running a docker image on an EC2 instance. When you run a docker image on an EC2 instance if that docker image crashes what will restart it? What if the EC2 instance itself fails? With ECS you give the container orchestrator an intent: "Run X copies of this container at all times, associated with this load balancer" Then you give the container orchestrator a place to launch stuff: either a cluster of EC2 instances, or AWS Fargate. Then the orchestrator continuously validates the state of your deployment and relaunches or moves containers as needed to serve your intent. You can even run spot instances to get up to 80% savings on your AWS bill, and if you get outbid on the spot market the container orchestration layer will move your containers to another machine. That in a nutshell is the benefit: the orchestrator lives outside of your instance and prevents the instance from being a failure point in your system, by separating your intent to run an application from the underlying resources that actually run it.