3 ms·
I know the Container world is full of idealistic developers who are busily waxing poetic about the benefits of portability and interoperability. But a Container
by stephengillie 11y ago
I know the Container world is full of idealistic developers who are busily waxing poetic about the benefits of portability and interoperability. But a Containerized app must still look to the OS for its DLLs and other underlying code.
To which end it looks like a Linux OS is required to run Apache containers, and a Windows OS would be required to run a .NET web app. Or we can run cross-OS binaries, aka WINE & Cygwin.
These files have to be somewhere. Unless we're baking them into the Container, at which point it's not much different than a VM.
Administration tools haven't been tied to the target platform for decades. A great many green administrators still connect directly to the platform to administer, but the tools to do the work from your own system have existed on almost every platform for a very long time.
Server farms need about 1 driver per microprocessor in each server's chassis. But this isn't about drivers, it's about not having to think about the part of the system you don't want to care about, to reduce your cognitive load.
- Animats 11y ago"Unless we're baking them into the Container, at which point it's not much different than a VM." A little more than a VM, but not much more. A file system (which might be on another machine) and a connection to a network interface are all that are necessary. .dll and .so files are part of the application, not part of the OS. Besides, static linking is making a comeback; Go and Rust are usually statically linked.
- nulltype 11y agoA docker container is basically statically linking your binary one level higher. Rather than just including the libraries, you include all the support files and other processes. A VM is then like the next level above that.