12 ms·
The article makes sense if portability was the only reason to use containers. Fat binaries solve the portability problem in a way that may or may not make sense
by mwfunk 9y ago
The article makes sense if portability was the only reason to use containers. Fat binaries solve the portability problem in a way that may or may not make sense for a given project, but fat binariries don’t address any of the other issues that container technologies provide solutions for (sandboxing, resource management, etc.). Either the author isn’t aware of these other issues, or is purposefully sweeping them under the the rug, because arguably they are more important than simple binary compatibility. I’d be pretty down on containers too if I thought they only existed in order to distribute portable binaries.
- SOLAR_FIELDS 9y agoPrecisely. As a real world example, I have a repository that basically is a large collection of code modules that runs on three different runtime environments. One of these run times is a Hadoop cluster, where we could happily shadowJar all of our massive dependencies (like Spark) into a giant multi-hundred-mb jar file and have no issues. Another one is a client desktop environment that is shipped to thousands of desktop users with each version release. Most of the code is reused between the two runtimes so it makes no sense to separate them. Therefore we build the project without the fat dependencies in the binary so we can ship the slim version to the client runtime without forcing huge download every release.