Yes, basically. You let the host manage memory, disk, network etc and your program is a guest OS that doesn't need all the extraneous processes that usually go with a whole OS. No background services or cron jobs.
Edit: as enduser pointed out, in addition to saving resources, this means there is no context-switching from kernelspace to userspace in your guest VM!
You let the host manage memory, disk, network etc and your program is a [process] that doesn't need all the extraneous processes that usually go with a whole OS. No background services or cron jobs.
Docker/cgroups/namespaces allow you to isolate multiple applications running in userspace on the same kernel to a very high degree.
This gets rid of isolation and multiprocessing altogether and runs a single application without any kernel at all (i.e. with just a very limited amount of support code linked in).
Put simply; the technology behind docker improves isolation between processes and this does the exact opposite.
I don't see how this, "...does the exact opposite," of what Docker does—both are very different approaches to the similar goals of having individual processes run in isolated ways. Docker does it by isolating individual running Linux processes under a single kernel, whereas unikernel-based systems do it by building those processes as lightweight programs that get compiled to their own kernel images and then running those on a hypervisor to achieve isolation.
Yes, you are right, this is not a binary classification and it really depends on the perspective. What I was trying to say is that - on some levels - the two approaches are almost antithetical.
Edit: as enduser pointed out, in addition to saving resources, this means there is no context-switching from kernelspace to userspace in your guest VM!