3 ms·
The thing is, fat binaries don't really solve the problem; Java and Go have just as many problems with this as python does because you're still depending on the
by overgard 7y ago
The thing is, fat binaries don't really solve the problem; Java and Go have just as many problems with this as python does because you're still depending on the OS. Your java app might still depend on a service running on the OS, or a system level configuration (hosts files, etc), or a JNI interface to a C library.
To me, Docker is a tradeoff: you're trading disk space and a little bit of efficiency for removing a TON of variables. Given that I have zero interest in debugging servers, that's a great win for me. YMMV. But if you have to potentially deal with thousands of servers, it seems like an obvious choice (excluding otherwise using something like a VM).
The JVM may have promised "write once run anywhere", but that's never really been particularly true. You've only ever really gotten that with an actual VM, and those are much heavier than Docker is
- smitty1e 7y agoThe joy of Docker seems to be minimizing the surface area of the API at the expense of some extra image size. I suppose the immutability of the layers amortizes the size cost as one starts to run ludicrous numbers of service copies.
- inferiorhuman 7y agoGiven that I have zero interest in debugging servers You're going to have to debug something, even with Docker. I still have nightmares about the Docker 12 rollout. The JVM may have promised "write once run anywhere", but that's never really been particularly true. You've only ever really gotten that with an actual VM, and those are much heavier than Docker is Which is to say that you don't get "write once run anywhere" with Docker either. In x86 land you'll still have differences (some more serious than others) between Docker on Linux, Mac (that still runs under a Linux VM, with all the networking hell that entails, right?), and Windows.
- pjmlp 7y agoJEE application servers take care of that.