super spicy take: shipping source, build systems, and containers (especially for ephemeral uses) instead of just shipping a compiled binary is a waste of electricity and arguments for the containerised delivery approach are not very compelling in practice unless you work for a cloud vendor.
@gsuberland I guess, to me at least, it depends on what you make of it.
There are containers that lean into the possibilities (an executable along with the absolutely required dependencies, maybe a dozen megabytes or two) and then there are "containers" that are just virtual machines in disguise (a full Ubuntu installation + runtime environment, source code and the aforementioned build system, so maybe a gigabyte)..
I think the former are a decent way to package services (but not tools).
Edited 226d ago
@jwarlander if you release your currently-Linux-only service as some code, a binary, and a text file describing install steps, I can probably port it to FreeBSD with no special knowledge.
if you release your service as a container I need to learn how your chosen container system works and reverse engineer the install requirements and steps from your compose file or whatever, and likely need to do extra work to get the build working in the first place.
@jwarlander my primary complaint here (which seems not to be what everyone is replying about, weirdly enough, funny how that happens) is that shipping a docker container full of commands to build the thing and then run it as a service makes bugger all sense over just building once for binary installs and offering a well-documented build and setup procedure for people who have other needs.
@gsuberland Oh! Yeah, definitely, containers aren't great as a general release method for software intended for others to use!
When replying above, I came from the context of my own situation - developing and deploying our own services that we run at work, in our cloud environment.