3 ms·

But then why not just use the VM itself and lose the container? Whatever restrictions you want to apply to the Docker, can be applied to the binary as well whe

But then why not just use the VM itself and lose the container? Whatever restrictions you want to apply to the Docker, can be applied to the binary as well when invoking it.

nyrikki 5y ago
While the choice of VM vs container is not one of good or bad in the general sense there are several reasons to choose containers. 1) Containers reduce the number of shared dependencies between the VM and the application. A container based on alpine will even be using musl libc vs glibc. And a VM running on a private cloud or different cloud providers will require different dependencies. As dependency hell is NP-complete, increasing the number of dependencies dramatically increases the effort of testing, trouble shooting, and maintaining a system. The simplified contract between a container and it's host vs a binary on a VM reduces that cost. 2) Instantiation time is much longer for a VM than a container. 3) Container management systems like k8 etc... tend to have more robust health checking, service registration, and recovery tools. If one is using containers already the cost of maintaining a parallel infrastructure for VMs is often high. 4) Developers can often run a container on their desktops/laptops and iterate faster as they avoid the challenges and costs in maintaining dependencies called out in #1 or the expense and time of spinning up development instances. There are companies and groups that use containers and container management systems because they are the hot new thing, but even before the public cloud or even high density VMs were a reality I was on a team that leverage Linux VServers for all core services. It is still the only company I have ever been at where we could actually switch over to a cold DR site with everything from DNS to Oracle EBS being up in less than half an hour. All with only using rsync and tar for a publicly traded company. You can get around package version selection being NP-complete by putting on other constraints like enforcing semantic versioning and auto updates. But IMHO using namespaces(containers) is one solution one should consider. Here is a link to a paper that will describe the package dependency problem generalizes to the NP-complete SAT problem. For me, containers are a way to limit that problem to being one of the container host only needing satisfy a contract for a far more limited set of needs (kernel ABI, network, storage). https://hal.inria.fr/hal-00697463 https://hal.inria.fr/hal-00697463 Your needs and challenges may be different, but containers tend to be a good option for many of the needs I have run across.

But then why not just use the VM itself and lose the container? Whatever restrictions you want to apply to the Docker, can be applied to the binary as well when invoking it.

nyrikki 5y ago

While the choice of VM vs container is not one of good or bad in the general sense there are several reasons to choose containers. 1) Containers reduce the number of shared dependencies between the VM and the application. A container based on alpine will even be using musl libc vs glibc. And a VM running on a private cloud or different cloud providers will require different dependencies. As dependency hell is NP-complete, increasing the number of dependencies dramatically increases the effort of testing, trouble shooting, and maintaining a system. The simplified contract between a container and it's host vs a binary on a VM reduces that cost. 2) Instantiation time is much longer for a VM than a container. 3) Container management systems like k8 etc... tend to have more robust health checking, service registration, and recovery tools. If one is using containers already the cost of maintaining a parallel infrastructure for VMs is often high. 4) Developers can often run a container on their desktops/laptops and iterate faster as they avoid the challenges and costs in maintaining dependencies called out in #1 or the expense and time of spinning up development instances. There are companies and groups that use containers and container management systems because they are the hot new thing, but even before the public cloud or even high density VMs were a reality I was on a team that leverage Linux VServers for all core services. It is still the only company I have ever been at where we could actually switch over to a cold DR site with everything from DNS to Oracle EBS being up in less than half an hour. All with only using rsync and tar for a publicly traded company. You can get around package version selection being NP-complete by putting on other constraints like enforcing semantic versioning and auto updates. But IMHO using namespaces(containers) is one solution one should consider. Here is a link to a paper that will describe the package dependency problem generalizes to the NP-complete SAT problem. For me, containers are a way to limit that problem to being one of the container host only needing satisfy a contract for a far more limited set of needs (kernel ABI, network, storage). https://hal.inria.fr/hal-00697463 https://hal.inria.fr/hal-00697463 Your needs and challenges may be different, but containers tend to be a good option for many of the needs I have run across.