Good to see that they're working on it, but I don't know why they don't fix the underlying paradigm instead of making it Cloudformation exclusive.
EDIT: I should mentioned that we are using AWS CDK for all of this. All it does is register a new task as the default task for a service and ECS/ALB does the rest.
I just want a cluster that scales in and out to the amount of memory my tasks need, I'm not very concerned about CPU. Until capacity providers it was more or less impossible to do so without having a bunch of excess capacity provisioned. Even with capacity providers, I can't seem to get a cluster to scale in to 0 instances when no tasks are needed.
I have one ECS service that requires an EBS volume mount, which means that when the task definition is updated, I need the service to stop, so that the new task can mount the same volume. This deployment model is essentially impossible without implementing a custom deployment strategy.
Fargate makes things a bit easier, and now that you can use EFS volumes with it it might make more sense. But overall, everything in ECS just seems poorly designed, clunky and hacky, like many AWS products.
https://gist.github.com/guillaumesmo/4782e26500a3ac768888daa...
There are so many - Elastic Beanstalk, ECS, EKS, ECS-on-Fargate, EKS-on-Fargate..and of course the huge marketing push for Serverless.
They could have the sensible way out and built EKS as the foundation of everything - makes total sense given the massive ecosystem around kubernetes. ECS and Fargate should be killed off.
https://cdk8s.io/ replaces Elastic Beanstalk ....but still basically runs on top of EKS.
The pairing of CDK8S and EKS are fundamentally enough for all usecases that AWS basically sells.
There is probably some tension between ECS and k8s - AWS built a container orchestration platform based on what they think the world (and Amazon) needs and then k8s became madly popular. And it's not clear that AWS was wrong because k8s is essentially too complex for many use cases. It makes total sense that they would support both fully.
IMO K8s will become akin to Linux Kernel. Almost no one uses bare mainline Linux kernels, you choose a distro based on your needs. Companies like RedHat and Canonical will pop up and provide their own packaged "distros" of K8s and you will choose which philosophy best suits your needs.
ECS predates EKS, and is better integrated than EKS with their other services. If you want a painless container experience on AWS, ECS for Fargate is what'll you'll want to use today. So both existing folks who use ECS today as well as new customers are going to keep using ECS.
Folks who like K8, perhaps from prior experience, are going to use EKS despite it having some rough corners.
See, Amazon is perfectly happy to support everything under the sun as long as there are paying users. See their database offering for very much the same strategy, and it would be silly to say that they should drop DB x since they now offer DB y.
And my whole point is that AWS is on the path to fix kubernetes UX and give you exactly the mental model you want...but run it on k8s.
Think of it as ECS, Beanstalk, Fargate on top of EKS.
You won't be asked to adopt the complexity of k8s
Same goes for Fargate, except that it’s now offered by EKS to, what possible reason would they have too turn it off?
image: !subst “image:${Tag}”There are basically three ways to do it:
Min less than max, max is 100.
Max greater than min, min is 100.
Some combination of the two.
For the first you take down running tasks first and then backfill with new (green) tasks.
For the second you add green tasks and once stable take down blue.
Make sure that if you only have two tasks that min/max move in 50% increments: I.e you can’t scale up/down to 125%/75% but can to 150%/50%.