5 ms·

Becuase 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

Becuase 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 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. Also docker can run applications that aren't shipped by people in your company and also does more stuff (like more sandoboxing and it also helps you with the resource management).

nix23 4y ago
>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.
- cies 4y ago
  > 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).
  - nix23 4y ago
    >They did, it failed, then the JVM was upgraded for dev/test See first error, dev/test has to be a exact mirror of production, otherwise it makes no sense. And if not even the admins from dev/test/production can communicate with each other...you really have deep rooted problem.
- imdsm 4y ago
  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.
- tetha 4y ago
  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.
  - nix23 4y ago
    Well yes you are absolutely right, the first comment who sees the down and upsides clearly.
- iolo 4y ago
  You can think of docker files and other manifests as a highly structured and more direct-to-machine form of communication. Instead of a developer informing other developers to ensure that the dev machines and servers are upgraded to the right version of the JVM via a confluence page or slack message, that developer has left machine-readable instructions in a consistent format in a readily accessible place. This is a good way to fix those problems with communication/practices/documentation and processes.
  - nix23 4y ago
    >This is a good way to fix those problems with communication/practices/documentation and processes. No it's not because the dev who made the database-container forgot to inform you that you need the new jdbc.jar etc...it's the same just with one more layer.
mschuster91 4y ago
> 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.
- nicoburns 4y ago
  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.
  - gtirloni 4y ago
    Sometimes it is. Depends on the vendor, of course, but I've seen them take many hours/days after a security fix is released.
- test1235 4y ago
  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.
  - formerly_proven 4y ago
    I don't use npm all that often, but I don't think I've ever run "npm install" in a project and not gotten any warnings about outdated dependencies and security vulnerabilities in them.
    - 4y ago

nix23 4y ago

>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.

cies 4y ago
> 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).
- nix23 4y ago
  >They did, it failed, then the JVM was upgraded for dev/test See first error, dev/test has to be a exact mirror of production, otherwise it makes no sense. And if not even the admins from dev/test/production can communicate with each other...you really have deep rooted problem.
imdsm 4y ago
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.
tetha 4y ago
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.
- nix23 4y ago
  Well yes you are absolutely right, the first comment who sees the down and upsides clearly.
iolo 4y ago
You can think of docker files and other manifests as a highly structured and more direct-to-machine form of communication. Instead of a developer informing other developers to ensure that the dev machines and servers are upgraded to the right version of the JVM via a confluence page or slack message, that developer has left machine-readable instructions in a consistent format in a readily accessible place. This is a good way to fix those problems with communication/practices/documentation and processes.
- nix23 4y ago
  >This is a good way to fix those problems with communication/practices/documentation and processes. No it's not because the dev who made the database-container forgot to inform you that you need the new jdbc.jar etc...it's the same just with one more layer.

mschuster91 4y ago

> 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.

nicoburns 4y ago
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.
- gtirloni 4y ago
  Sometimes it is. Depends on the vendor, of course, but I've seen them take many hours/days after a security fix is released.
test1235 4y ago
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.
- formerly_proven 4y ago
  I don't use npm all that often, but I don't think I've ever run "npm install" in a project and not gotten any warnings about outdated dependencies and security vulnerabilities in them.
  - 4y ago