[skar5151]

Good article. Would love if you share thoughts on tracking container density during scheduling and orchestration. Containers on VMs is like going backwards in design. VM tools have made life easy with auto-scaling et all on public clouds, however the future is containers on bare metal. Gets you much higher performance and server density #vmless.

[altsang]

That's true to a certain degree. Bare metal VMs running containers server give you OS ioslation but at a cost of an abstraction layer that is not necessarily needed if your interest is only at the container level. That's pretty much why CoreOS, RancherOS and other technologies are out there to be as slim of an OS to just run containers and the bare minimum system processes required. Even system processes are run as containers in RancherOS! APM and other system monitoring tools need to be tweaked for a huge multiplier of processes that are now your distributed app versus that one process that might've been your JVM for example. There's a concerted ops and devops effort that's required to hook into your orchestration layer to get that kind of insight. Roman's next post is going to cover the reasons why we chose the OSS orchestrator that we did.

When it comes to APIs and microservices, you're almost inevitably faced with container sprawl - especially with the ability to deploy quickly and deploy often. Having a good orchestration as described in this post gives you the ability to mind those containers across multiple machines - bare metal or VM, doesn't matter.