One of the more interesting announcements. ECS has seemed like a non starter for any "serious" project for a while, but as someone who has been implementing mesos for the last few months, its pretty interesting that they would prioritize pluggable schedulers rather than getting better feature parity with kubernetes on google cloud.<p>Pluggable schedulers is one of the best features that is missing from kubernetes, swarm, and nomad. All the scheduling/lifecycle algorithms are pretty naive when it comes to any stateful (DBs, kafka) or batch (hadoop, spark) services. But even for typical webapps, pluggable schedulers give you a nice place to hook into a lot of the lifecycle that makes things like pre-warming or cleanly killing sockets at scale down a lot simpler.<p>So this is pretty cool... and makes ECS more attractive... but I wish it was just mesos which is built around the idea of providing a framework for building schedulers and would be way more portable.
In case it wasn't clear to anyone else, this is by the Amazon ECS team. An introductory blog post is here: <a href="https://aws.amazon.com/blogs/compute/introducing-blox-from-amazon-ec2-container-service/" rel="nofollow">https://aws.amazon.com/blogs/compute/introducing-blox-from-a...</a>
I am really glad to see this kind of thing. I built an important project on ECS at the beginning of this year, and it was an extremely frustrating uphill battle, and I consider myself a seven or eight out of ten with containers and container orchestration in general. I wanted so much to enjoy working with ECS, especially because it was the first major Docker project that particular client was working with, and I wanted to blow their minds. The choice to build on ECS was the client's (not mine), and ECS made their introduction to container orchestration lukewarm at best. Because of those obstacles, I have been recommending <i>against</i> using ECS. Seems like it's time for me to evaluate ECS once more to see how far it's come along.