4 ms·

"Docker shouldn't exist. It exists only because everything else is so terribly complicated that they added another layer of complexity to make it work. It's lik

by apienx 4y ago

"Docker shouldn't exist. It exists only because everything else is so terribly complicated that they added another layer of complexity to make it work. It's like they thought: if deployment is bad, we should make development bad too. It's just... it's not good." Jack's not wrong. But better to look at it as throwing (increasingly cheaper) compute at the it-runs-on-my-machine problem.

doctor_eval 4y ago
When I lived in the Java world, Docker solved a heap of problems because Java has so many external dependencies - you needed the JVM, all its libraries, and all sorts of configuration files for those libraries. But how is a docker image different from, for example, a statically compiled single-binary Go executable? Because when I work with Go, I tend to think that if what I'm working on requires something defined from outside the binary, I'm doing it wrong. So is Docker a solution to problems that are inevitable, or is it just a solution to problems caused by other solutions? These days I tend to think that something like Firecracker is more likely to be a solution to deployment problems than Docker is, but I haven't tried it yet...
- vbezhenar 4y ago
  I live in Java world and docker solves exactly 0 problems for me. Maven or Gradle deals with assembling all the necessary jars into a single directory (or uberjar if you want, I don't like it). JVM is another directory. Running application is a shell script of 2-3 lines. So my Java application is: directory with JVM, directory with jars and start.sh. It works almost everywhere. It's simpler than docker. I can replace JVM with windows version and start.sh with start.bat and it'll run on Windows. Natively. Can't do that with Docker. To build my application one would need to have maven (one directory), JVM (another directory) and project sources. Set up two env vars (JAVA_HOME, PATH) and run mvn verify. That's about it. Windows, Linux, macOS, doesn't matter. Single binary is simpler than a directory with some files. But not much simpler. I use docker, because that's the way things are done nowadays. I think that for personal project which does not need Kubernetes, I wouldn't use it.
  - bjconlan 4y ago
    I totally agree with and think we've all accepted it's (docker/oci's) place regarding deployability on infrastructure not managed by java developers. Recently I've done a few migration projects and the biggest pain-point (not really a pain but not k8 friendly) is the containerization of JEE servers/services. As these solved most of what containers provide (deployment wise) albeit only for java. 'DevOps' generally killed this (and the related tech debt) but it's hard to validate the utility of any of this as the 'generalized' solution feels like it's compromised down to a point of convenience. In saying that I do enjoy having a deployment platform that is always going to be Linux(like). I don't think I would use it either for a personal project; but I would perhaps investigate how hard it would be to add some level of "kublet" (cri) like jvm integration
- lmm 4y ago
  > When I lived in the Java world, Docker solved a heap of problems because Java has so many external dependencies - you needed the JVM, all its libraries, and all sorts of configuration files for those libraries. Lol, no you don't. You need a fat jar and you need to install the JVM on your servers (and, sure, maybe upgrade it once every three years). In the early days people actually used Java to do the same thing that docker does, by having an "application server" that you would deploy individual java apps into, before realising what a bad idea that was. > So is Docker a solution to problems that are inevitable, or is it just a solution to problems caused by other solutions? It's a solution to the problem that Python dependency management sucks. Unfortunately the last 6 or 7 iterations of "no, Python dependency management is good now, we've fixed it this time, honest" suggest that that's inevitable.
  - doctor_eval 4y ago
    > It's a solution to the problem that Python dependency management sucks. Unfortunately the last 6 or 7 iterations of "no, Python dependency management is good now, we've fixed it this time, honest" suggest that that's inevitable. I didn't mean to imply that I think Docker exists solely for Java; I didn't realise that Python has the same problems, but it's unsurprising, and there are plenty of other languages/platforms that probably have the same problem. My point was that I have started to think that Docker is a solution to a problem that probably shouldn't exist. > Lol, no you don't. You need a fat jar and you need to install the JVM on your servers (and, sure, maybe upgrade it once every three years). In the early days people actually used Java to do the same thing that docker does, by having an "application server" that you would deploy individual java apps into, before realising what a bad idea that was. I'm surprised that you advocate for deploying JVMs to individual production servers; given that Docker exists, per-server JVM installs are quite possibly the worst possible way to manage Java deployment in a production environment. Give me Docker over this any day. Docker is great for Java apps. As someone else pointed out, one of the benefits of Docker is that you get rid of the "it-runs-on-my-machine" problem: if you want your application to run reliably throughout dev, test and prod, then you must include the JVM in the distribution, because you can't otherwise guarantee that the JVM you're running on is the one you developed and/or tested on. Don't even get me started on JavaEE: an operating system built by consultants, for consultants.
- 0x445442 4y ago
  Sorry but from a Java perspective I fail to see Docker as an improvement over deploy war.
  - doctor_eval 4y ago
    Well for one thing Docker tends to keep running for a long time while the several JEE App servers I used all needed rebooting after a few deploys just to keep them running. I mean ... don't even get me started, Java app servers were a nightmare and I was so very happy when we were able to ditch ours and go back to a sane architecture.
    - 0x445442 4y ago
      Hmm, WebSphere was solid as a rock when I used it in production.
      - doctor_eval 4y ago
        History hasn’t really been kind to JavaEE though.
SoftTalker 4y ago
Docker is a resoponse to the rejoinder of "works on my machine" when there is a production problem. Rather than working out why there is a problem in production, it's bascically a way tojust run the dev machine in production. Never been sure why anyone thought that was a great idea, but I guess it does solve that one issue.
dqpb 4y ago
Docker is an interesting thing. I really love what I'm able to do with it. But I despise when people make it a necessary component of the development environment.
esjeon 4y ago
It's not really about Docker. If the software was easy, we wouldn't need Docker this much in the first place. But software sucks, so we wrap it in Docker, but now Docker sucks, because we simply gathered all the shits so that it spills everywhere now. Also, some of the shit is from Docker itself.

by apienx 4y ago

doctor_eval 4y ago

When I lived in the Java world, Docker solved a heap of problems because Java has so many external dependencies - you needed the JVM, all its libraries, and all sorts of configuration files for those libraries. But how is a docker image different from, for example, a statically compiled single-binary Go executable? Because when I work with Go, I tend to think that if what I'm working on requires something defined from outside the binary, I'm doing it wrong. So is Docker a solution to problems that are inevitable, or is it just a solution to problems caused by other solutions? These days I tend to think that something like Firecracker is more likely to be a solution to deployment problems than Docker is, but I haven't tried it yet...

vbezhenar 4y ago
I live in Java world and docker solves exactly 0 problems for me. Maven or Gradle deals with assembling all the necessary jars into a single directory (or uberjar if you want, I don't like it). JVM is another directory. Running application is a shell script of 2-3 lines. So my Java application is: directory with JVM, directory with jars and start.sh. It works almost everywhere. It's simpler than docker. I can replace JVM with windows version and start.sh with start.bat and it'll run on Windows. Natively. Can't do that with Docker. To build my application one would need to have maven (one directory), JVM (another directory) and project sources. Set up two env vars (JAVA_HOME, PATH) and run mvn verify. That's about it. Windows, Linux, macOS, doesn't matter. Single binary is simpler than a directory with some files. But not much simpler. I use docker, because that's the way things are done nowadays. I think that for personal project which does not need Kubernetes, I wouldn't use it.
- bjconlan 4y ago
  I totally agree with and think we've all accepted it's (docker/oci's) place regarding deployability on infrastructure not managed by java developers. Recently I've done a few migration projects and the biggest pain-point (not really a pain but not k8 friendly) is the containerization of JEE servers/services. As these solved most of what containers provide (deployment wise) albeit only for java. 'DevOps' generally killed this (and the related tech debt) but it's hard to validate the utility of any of this as the 'generalized' solution feels like it's compromised down to a point of convenience. In saying that I do enjoy having a deployment platform that is always going to be Linux(like). I don't think I would use it either for a personal project; but I would perhaps investigate how hard it would be to add some level of "kublet" (cri) like jvm integration
lmm 4y ago
> When I lived in the Java world, Docker solved a heap of problems because Java has so many external dependencies - you needed the JVM, all its libraries, and all sorts of configuration files for those libraries. Lol, no you don't. You need a fat jar and you need to install the JVM on your servers (and, sure, maybe upgrade it once every three years). In the early days people actually used Java to do the same thing that docker does, by having an "application server" that you would deploy individual java apps into, before realising what a bad idea that was. > So is Docker a solution to problems that are inevitable, or is it just a solution to problems caused by other solutions? It's a solution to the problem that Python dependency management sucks. Unfortunately the last 6 or 7 iterations of "no, Python dependency management is good now, we've fixed it this time, honest" suggest that that's inevitable.
- doctor_eval 4y ago
  > It's a solution to the problem that Python dependency management sucks. Unfortunately the last 6 or 7 iterations of "no, Python dependency management is good now, we've fixed it this time, honest" suggest that that's inevitable. I didn't mean to imply that I think Docker exists solely for Java; I didn't realise that Python has the same problems, but it's unsurprising, and there are plenty of other languages/platforms that probably have the same problem. My point was that I have started to think that Docker is a solution to a problem that probably shouldn't exist. > Lol, no you don't. You need a fat jar and you need to install the JVM on your servers (and, sure, maybe upgrade it once every three years). In the early days people actually used Java to do the same thing that docker does, by having an "application server" that you would deploy individual java apps into, before realising what a bad idea that was. I'm surprised that you advocate for deploying JVMs to individual production servers; given that Docker exists, per-server JVM installs are quite possibly the worst possible way to manage Java deployment in a production environment. Give me Docker over this any day. Docker is great for Java apps. As someone else pointed out, one of the benefits of Docker is that you get rid of the "it-runs-on-my-machine" problem: if you want your application to run reliably throughout dev, test and prod, then you must include the JVM in the distribution, because you can't otherwise guarantee that the JVM you're running on is the one you developed and/or tested on. Don't even get me started on JavaEE: an operating system built by consultants, for consultants.
0x445442 4y ago
Sorry but from a Java perspective I fail to see Docker as an improvement over deploy war.
- doctor_eval 4y ago
  Well for one thing Docker tends to keep running for a long time while the several JEE App servers I used all needed rebooting after a few deploys just to keep them running. I mean ... don't even get me started, Java app servers were a nightmare and I was so very happy when we were able to ditch ours and go back to a sane architecture.
  - 0x445442 4y ago
    Hmm, WebSphere was solid as a rock when I used it in production.
    - doctor_eval 4y ago
      History hasn’t really been kind to JavaEE though.

SoftTalker 4y ago

Docker is a resoponse to the rejoinder of "works on my machine" when there is a production problem. Rather than working out why there is a problem in production, it's bascically a way tojust run the dev machine in production. Never been sure why anyone thought that was a great idea, but I guess it does solve that one issue.

dqpb 4y ago

Docker is an interesting thing. I really love what I'm able to do with it. But I despise when people make it a necessary component of the development environment.

esjeon 4y ago

It's not really about Docker. If the software was easy, we wouldn't need Docker this much in the first place. But software sucks, so we wrap it in Docker, but now Docker sucks, because we simply gathered all the shits so that it spills everywhere now. Also, some of the shit is from Docker itself.