Why even use ECS when you can just start an Elastic Beanstalk docker-based cluster, and get superior, more focused web UI (at least the UI for EB is superior at present) along with much easier configuration?
If I sound bitter, it's because I am -- I recently spent about 2 days straight trying to build an ECS cluster reliably with CloudFormation, and while I must admit I was newer than normal to CloudFormation templates, the amount of errors I ran into (and incredibly slow provision/creation/update time), along with the broken edge cases (try and make an existing EC2 bucket with CloudFormation) was infuriating. Don't read any further if you don't want to read a rant.
While ECS is great in theory (or if you set it up by clicking tons of buttons on AWS's UI), it's significantly harder to automatically deploy than BeanStalk is, from where I'm standing. All I have to do is get a container with the eb command line tool installed, do a bunch of configuration finangling (which honestly is ridiculous as well, just let me give you a file with all my configuration in it, or read it from ENV, and stop trying to provide interactive CLIs for everything, for fucks sake) and I can run `eb deploy` and push a zip file with nothing but a docker container (muilti container setups are also allowed) specified up to the cloud. Later I'm going to look into using CloudFormation to set up EB, but I know even that will be simpler, because I won't have to try and make any ECS::Service objects or ES::TaskDefinitions.
Trying to use ECS made me so glad that Kubernetes exists. Unfortunately in my work I can't use it currently because that would mean the rest of the team stopping to learn it, but Cloudformation + ECS is a super shitty version of setting up a kubernetes cluster and using a kubernetes resource config file. I think the best part about kubernetes is that if the community keeps going the way it's going, cloud providers will finally be reduced to the status of hardware vendors -- all I'll need from EC2 is an (overpriced) machine, network access, and an IP, not to try and keep up with it's sometimes asinine contraptions and processes, or be locked in to their ecosystem.
Yeah maybe it just wasn't for me -- with RDS as the database and ElastiCache for redis, all we needed was to run the API server (one container, we don't even have any like queue job workers or anything). When I started looking into how to run containers on AWS ECS seemed like the best fit.
Sort of. You can actually do a multi-container deployment in Elastic Beanstalk. I did that the other day with 1 EC2 instance and it deployed both containers to the same instance. I don't know what the behavior is if you have multiple containers and multiple VMs though.
One of the other annoying limitations of a single container deployment on Elastic Beanstalk is that you can only open a single port to the docker container - which is really problematic in a lot of situations.
I am probably wrong but it sounds your problems were mostly with Cloudformation. But I think there are options for the provision, you could use the cli or you could use third party tools like terraform.
I haven’t tried it but maybe Fargate would it be an option?
I partly considered not writing the original post because this thought crossed my mind as well -- I think that it IS a problem with ECS because just about every other S3 object was easy to create and consistent when I would apply the configurations. The ECS Service just seemed to be less stable.
Also, I was using the AWS code SDK to build a little deploy script and it actualy worked really great. The reason I can't use a third party tool like terraform is because I can't force the rest of the team to learn about it (similarly why I can't use kubernetes)
Right, that's what I mean -- I use the web ui the first time to get the feel for the service (in this case EC2), then try to make it permanent with CloudFormation, prompting a deep dive into the reams of documentation and CloudFormation API docs. My problem was the amount of surprises that I came into contact with trying to write a consistently working CloudFormation for ECS. I wrote a CloudFormation config that would succeed, then I'd shut it down, then it'd fail -- that happening absolutely decimated any trust I had for the effectiveness of the orchestration of an ECS.
Out of all the pieces that were being spun up/down, the ECS Service was the shakiest/hardest to model in my own mind -- every time I got an error from it it would make me scratch my head, even looking at the created instance in the web UI. Maybe this is all just attributable to lack of operator knowledge, but I don't think so because at this point I know _exactly_ the EC2 objects I want to make, but after my experice with trying to set up ECS I'd rather not try again. The documentation is extensive though, so I am very thankful to AWS for that.
Also, of course, all of this takes a pretty long time -- though to be fair, AWS is instantiating AMIs in this time, much harder than just spinning up a container like a kubernetes cluster would have to do.
That said, I don't think it's unreasonable to want the UI to be good, it's just the case that for AWS it typically is not, and it doesn't lend itself to creating good cross-region, immutable-style infrastructure. I see no reason why the UI couldn't theoretically be good enough here for most typical use pieces though. I guess that just goes against AWS's approach of giving you every building block imaginable rather than a coherent platform.
If I sound bitter, it's because I am -- I recently spent about 2 days straight trying to build an ECS cluster reliably with CloudFormation, and while I must admit I was newer than normal to CloudFormation templates, the amount of errors I ran into (and incredibly slow provision/creation/update time), along with the broken edge cases (try and make an existing EC2 bucket with CloudFormation) was infuriating. Don't read any further if you don't want to read a rant.
While ECS is great in theory (or if you set it up by clicking tons of buttons on AWS's UI), it's significantly harder to automatically deploy than BeanStalk is, from where I'm standing. All I have to do is get a container with the eb command line tool installed, do a bunch of configuration finangling (which honestly is ridiculous as well, just let me give you a file with all my configuration in it, or read it from ENV, and stop trying to provide interactive CLIs for everything, for fucks sake) and I can run `eb deploy` and push a zip file with nothing but a docker container (muilti container setups are also allowed) specified up to the cloud. Later I'm going to look into using CloudFormation to set up EB, but I know even that will be simpler, because I won't have to try and make any ECS::Service objects or ES::TaskDefinitions.
Trying to use ECS made me so glad that Kubernetes exists. Unfortunately in my work I can't use it currently because that would mean the rest of the team stopping to learn it, but Cloudformation + ECS is a super shitty version of setting up a kubernetes cluster and using a kubernetes resource config file. I think the best part about kubernetes is that if the community keeps going the way it's going, cloud providers will finally be reduced to the status of hardware vendors -- all I'll need from EC2 is an (overpriced) machine, network access, and an IP, not to try and keep up with it's sometimes asinine contraptions and processes, or be locked in to their ecosystem.