The main reason to use Docker are the reproducible environments. Today, applications, have a lot of dependencies. In the application I am working, I have to install like ten different software programs and libraries only to be to run it, and I have to use concrete versions. If you work with other people, it is very tedious to have to install and configure all manually.
With Docker you can make sure all of you are using the same kernel version with the same dependencies. So, also you can avoid, bugs derived from strange software versions combination.
Ask HN: Docker vs simple DLLs?
21–30 of 65 posts
Re: Ask HN: Docker vs simple DLLs?
#22It’s a different conversation from the dev side and from the sysadmin side, and neither might apply to you. As a dev, containers allow you to care a lot less about what’s installed on the server and in which version. You’ve already solved that in a different way for your setup, which is fine. I’d say the trick in your case isn’t the DLLs specifically (I’m not sure why you focus on that aspect), it’s the fact that .NE…
> I’m not sure why you focus on that aspect
Ah that was because in the video I watched on docker, the guy gave the example of one application using node v14 and another application using node v9 on the same machine, so I was like why aren't they just separate precompiled files like nuget packages.
Great explanation though, thanks!
Re: Ask HN: Docker vs simple DLLs?
#23Becuase your solution is specific to your specific software. Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe. And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. The th…
> The thing with docker is that you just get a complete package with everything delivered directly by the developer and it's very hard to mess up.
The downside is: you are also, at the same time, excluding yourself from standard patch management. Whereas in ye olde times for a situation like Heartbleed or log4shell the 24/7 on-call sysop team would run a simple "apt-get upgrade openssl" and restart all affected daemons, under modern "devops"/docker-centric models you need to wait for the developers or, worse, the container image vendor to deliver updated versions.
Re: Ask HN: Docker vs simple DLLs?
#24Becuase your solution is specific to your specific software. Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe. And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. The th…
>And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. That's just a sing for bad communication/practices/documentation and processes, and why don't the dev's test the application on the dev/test-environment? BTW: Why can the JAVA-team even install something on the dev/test/prod-env? That's completely against the rules.
> why don't the dev's test the application on the dev/test-environment?
They did, it failed, then the JVM was upgraded for dev/test (but not yet for prod as that was still running the prev-JVM version of the code).
Re: Ask HN: Docker vs simple DLLs?
#25Docker helps with two problems DLLs dont: 1) what if I want to run your app on my Linux server and I dont have dotnet set up. I dont want to deal with installing and maintaining dontnet. And I dont trust your setup script 2) You want run a database and message as part of your application, and they aren't dotnet.
> And I dont trust your setup script
Worth pointing out that if you don't trust their setup script, then you probably shouldn't trust their Docker container either.
Re: Ask HN: Docker vs simple DLLs?
#26Becuase your solution is specific to your specific software. Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe. And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. The th…
>And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. That's just a sing for bad communication/practices/documentation and processes, and why don't the dev's test the application on the dev/test-environment? BTW: Why can the JAVA-team even install something on the dev/test/prod-env? That's completely against the rules.
Because in reality, with large teams, communication is expensive.
Containerisation allows reproducibility, in a self-documenting manner. Delivery can be automated, depended upon to run, in a totally system configuration agnostic manner. It allows projects to deliver their software in a way that it can be ran, instantly, with a single command (image download not withstanding).
I've worked heavily in service software engineering for over a decade now, and with docker since 2013, and it has changed everything. There will be some people who don't fully understand it, but perhaps they don't have the problems that it solves and thus don't need it.
Alternatively, they /could/ just be suffering without realising there is a solution.
Re: Ask HN: Docker vs simple DLLs?
#27Becuase your solution is specific to your specific software. Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe. And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. The th…
> The thing with docker is that you just get a complete package with everything delivered directly by the developer and it's very hard to mess up. The downside is: you are also, at the same time, excluding yourself from standard patch management. Whereas in ye olde times for a situation like Heartbleed or log4shell the 24/7 on-call sysop team would run a simple "apt-get upgrade openssl" and restart all affected daemo…
Is depending the container image vendor actually worse? I was under the impression that they were about as "on it" as the distro maintainers with updates. And if you wanted full control then you could just have your sysadmins manage their own base images. Then upgrading system dependencies becomes as simple as doing a regular deploy.
Re: Ask HN: Docker vs simple DLLs?
#28Becuase your solution is specific to your specific software. Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe. And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. The th…
> The thing with docker is that you just get a complete package with everything delivered directly by the developer and it's very hard to mess up. The downside is: you are also, at the same time, excluding yourself from standard patch management. Whereas in ye olde times for a situation like Heartbleed or log4shell the 24/7 on-call sysop team would run a simple "apt-get upgrade openssl" and restart all affected daemo…
I feel like I get this a lot with the NPM cli tool ... No matter how often I update my dockerfiles to the latest version, I'll always end up with a big banner warning message in my build output telling me I'm outdated 'cos it seems NPM updates (and publishes) constantly.
Re: Ask HN: Docker vs simple DLLs?
#291) Most software isn’t purely a collection of executable code. Usually there’s some configuration stored somewhere. (Files, registry, whatever.) Containerization ensures that we have one self-executing file that contains all of that state.
At this point you might respond with “I could zip up all that state and still make sure it unzips to a single folder” But that leads us to
2) Most production software has at least one dependency that needs isolation. Even if you’re good about making sure that you follow the rules to make folders self-isolating, eventually you’ll have to take a dependency made by someone who isn’t following the rules.
Re: Ask HN: Docker vs simple DLLs?
#30Becuase your solution is specific to your specific software. Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe. And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. The th…
>And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. That's just a sing for bad communication/practices/documentation and processes, and why don't the dev's test the application on the dev/test-environment? BTW: Why can the JAVA-team even install something on the dev/test/prod-env? That's completely against the rules.
Yes. However, with more and more teams, and more and more languages, this communication, and especially planning and executing these upgrades and changes while providing rollbacks for all languages becomes harder and harder. It's very possible to do this, but it takes a lot of effort.
Containerization largely eliminates this need for communication. There are new problems - security of running containers, image sizes, building images safely and so on, but this problem disappears.