On the other hand ECS does a much more intelligent deployment approach. Basically when a service is updated it creates a new container to replace one of the old ones, wait for an old one to drain, then switches it out with the new one, etc, until all the containers are replaced with the updated container.
Basically if you are doing CI and want to have many zero downtime deploys per day with no service interruption then ECS does it much more gracefully. Additionally if your service is really large, requiring a lot of instance resources then EB requires you to run two copies of your environment in parallel, at least during deploys, which can be quite expensive. ECS just swaps out containers on the running hardware, so you just need a few extra instances for wiggle room when deploying, but you don't have to launch another parallel copy of your stack.
I don't believe this is accurate. When making radical changes to your application it might be required to run two copies in EB and do a CNAME swap.
But for day-to-day deploys of new versions, EB can use rolling batches within one application, as you say ECS does, you configure it to.
Specifically, you can have EB update only a fixed number or percentage of instances in your application with new versions at a time. It does this by removing, in batches, only some of the instances from the load balancers, waiting for existing connections to complete, updating those instances, and then re-adding them to the load-balancer.
(I agree that the existence of this page along with "Deploying Versions with Zero Downtime" is confusing, but rolling deploys are specifically mentioned as an alternative to CNAME swap: "Batched application version deployments are also an alternative to application version deployments that involve a CNAME swap")
Also, regarding terminology, note that under the hood EB, when used for multi-container Docker applications, is just an abstraction layer over ECS. It sets up ECS tasks for you you.
Elastic Beanstalk is a wrapper for multiple AWS services. The Docker multi container version uses ECS for containers. Using ECS directly can be more work but it also gives more control.
EB works the same way for VMs, it will integrate with EC2 for you or you can use EC2 directly instead of EB.
NathanKP|10 years ago
Due to the way EB works the only way to get zero downtime deploys in EB is by having two environments and swapping their CNAMES:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-...
On the other hand ECS does a much more intelligent deployment approach. Basically when a service is updated it creates a new container to replace one of the old ones, wait for an old one to drain, then switches it out with the new one, etc, until all the containers are replaced with the updated container.
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/u...
Basically if you are doing CI and want to have many zero downtime deploys per day with no service interruption then ECS does it much more gracefully. Additionally if your service is really large, requiring a lot of instance resources then EB requires you to run two copies of your environment in parallel, at least during deploys, which can be quite expensive. ECS just swaps out containers on the running hardware, so you just need a few extra instances for wiggle room when deploying, but you don't have to launch another parallel copy of your stack.
deet|10 years ago
But for day-to-day deploys of new versions, EB can use rolling batches within one application, as you say ECS does, you configure it to.
Specifically, you can have EB update only a fixed number or percentage of instances in your application with new versions at a time. It does this by removing, in batches, only some of the instances from the load balancers, waiting for existing connections to complete, updating those instances, and then re-adding them to the load-balancer.
See http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-...
(I agree that the existence of this page along with "Deploying Versions with Zero Downtime" is confusing, but rolling deploys are specifically mentioned as an alternative to CNAME swap: "Batched application version deployments are also an alternative to application version deployments that involve a CNAME swap")
Also, regarding terminology, note that under the hood EB, when used for multi-container Docker applications, is just an abstraction layer over ECS. It sets up ECS tasks for you you.
rossf7|10 years ago
EB works the same way for VMs, it will integrate with EC2 for you or you can use EC2 directly instead of EB.