Even if i skipped the spaceship whole analogy section (I did), all in all really glad to see more easily accessible explanations for AWS technology than the main documentation. I love how approachable this is, and the diagrams help.
I've had a lot of good experiences with ECS so far, except for their scheduled tasks system. With cron, you check /var/mail. When a scheduled task doesn't run on ECS... you're SOL.
For those looking for a more in-depth explanation of Amazon ECS, I highly recommend the videos here <a href="https://awsdevops.io/p/hitchhikers-video-guide-aws-docker" rel="nofollow">https://awsdevops.io/p/hitchhikers-video-guide-aws-docker</a>
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?<p>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.<p>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.<p>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.
So many things are janky in ECS that it ends up costing too much time and energy to get anything done. I've posted at length before about all the specific problems I hit while building on ECS, but lately I've just been telling people that it's like that janky toolbox in the funny old "PHP is a fractal of bad design" blog post [0]. Of all the AWS services I ever used, I find ECS <i>by far</i> the most terrible. Even worse than Amazon's documentation. So this really stunted and awkward spaceship analogy is pretty hilarious, given that it's about ECS.<p>[0] <a href="https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/" rel="nofollow">https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/</a>
I happen to be working on this and since there's a thread why not ask...<p>Has anyone gotten "multi-tenant" (default-restricted) overlay network(s) working on ECS in a way that they like?