This is interesting when compared to Amazon Elastic Container Service because of Azure Container Service's support for native Docker clustering tools.
If I am developing user docker-compose, I want to deploy that way, too - at least until I reach scale, at which point I want scheduling and orchestration tools, e.g. Swarm.
For easier disaster recovery, it's very convenient if these scheduling/orchestration tools let you deploy in the same way cross-cloud-provider. Swarm can run on AWS/Azure/GCE/bare metal, whereas ECS (which doesn't support Swarm and has its own scheduling/orchestration toolset) can only run on ECS.
+1 to MS for thinking about native tooling up-front.
One of our primary goals with ACS is to make sure we offered versatility with the platform. We wanted to support both a choice of orchestrators (DCOS and Swarm) and wanted to expose these open source solutions directly, enabling cross-cloud mobility.
It's honestly already pretty freaking good. If you allow for the fact that Go is a less rich language (syntactically) than Java, I'd even suggest that VSC for Go is on par with IDEA products for their respective languages. There's definitely stuff to improve yet, but the day-to-day stuff is smooth as silk.
If I am developing user docker-compose, I want to deploy that way, too - at least until I reach scale, at which point I want scheduling and orchestration tools, e.g. Swarm.
For easier disaster recovery, it's very convenient if these scheduling/orchestration tools let you deploy in the same way cross-cloud-provider. Swarm can run on AWS/Azure/GCE/bare metal, whereas ECS (which doesn't support Swarm and has its own scheduling/orchestration toolset) can only run on ECS.
+1 to MS for thinking about native tooling up-front.