The current app container model as it is takes the form of binary images managed by a de facto runtime that enforces namespace, cgroup and other boundaries by u

The current app container model as it is takes the form of binary images managed by a de facto runtime that enforces namespace, cgroup and other boundaries by using kernel subsystems for logical partitioning. Unlike system containers like LXC, appc means you now have an explosion of the state space whereby every container has their own independent copy of a host OS, yet relies on the semantics of its container manager to function, i.e. it is not easily introspectable with vanilla tools. So you end up needing to build a small parallel userspace to handle things like service discovery, orchestration and provisioning, networking bridges, location transparency, resource scheduling and taken to its logical conclusion you start running a user-mode kernel (Mesos) on top of a base OS kernel (Linux) to provide further abstractions of OS resources and run extended versions of OS processes called frameworks. I don't know if it's too early to tell, but I think people might have dug themselves into a ditch where in an attempt to escape the limitations of their kernel and userland, they've only expanded it with a concurrent layer and must maintain both.