I find this attitude interesting. By the same reasoning why are .debs better than building from source, and the ultimate - horse drawn buggies vs automobiles.
I've seen containerized applications described as "statically linked apps", it's one blob with dependencies included. I'm moving in that direction (vs cap-style deployments) because it guarantees that all machines are identical (from QA to staging, to production). Spinning up additional machines becomes trivial.
Interesting, that’s the opposite of my experience. Containers allow bundling up lots of dynamic dependencies together so that they can be installed as a single unit. Static binaries can just be deployed as a single file, no need for containers.
I think the main thing is to provide an abstraction for applications so that they aren't tightly coupled to the operating system of the server that's hosting them. That's a big deal.
Some people have mentioned security...patching in particular. Containers won't help if you don't have patching down. At the very least it lets you patch in the lab and easily promote the entire application into production.
I think that the security arguments are a canard. By making it easier and faster to deploy you should be able to patch app dependencies as well. I, for one, would automate the download and install of the latest version of all libs in a container as part of the app build process. Hell, build them all from source.
IT departments need to be able to easily move applications around instead of the crazy build docs that have been thrown over the wall for years.
Static binaries are congruent to containers, in a way. Both bundle an app and dependencies together. There are advantages and disadvantages to both approaches, but Docker-style containers are more elegant in some ways.
Is containerization any better than static binaries for compiled apps (not talking about python/ruby/js apps here, but instead compiled ones like firefox)?
It’s worth noting that advantage (and in my belief the large adoption of containers generally) is only valuable to interpreted languages that dont allow static linking.
For statically compiled binaries I’ve not worried about different versions of libraries for my binaries for 20 years (and the technology is decades older than that).
I do appreciate the docker file format but largely because it’s become used for true virtualization systems like firecracker. Plain Linux “containers” largely offer me very little.
This isn't a virtue. Containers solve problems in automated continuous-deployment environments where rebuilding and deploying your fleet of cattle is one click away. In the best case, no single container is alive for more than O(hours). Static linking solves way more operational problems than the loss of dynamic linking introduces, security or otherwise.
This kind of reminds me of just statically linking everything. We have not done that because it is a waste of resources but containers are all right then. :)
(OK, I'm aware of the differences, but I don't see containers as a salvation for client-side deployment.)
> The problems of updating applications individually because they're statically compiled are insignificant compared to the problems that come from having to do everything within containers.
Bundling dependencies aren't the only reason containers are used though. We still want to sandbox everything, and those sandboxes need to provide dependencies.
At least with dynamically linked you can decouple and share things like "runtimes" in the flatpak vernacular, which does have some advantages like dependency security updates.
Docker containers, like shipping containers is about reaping the benefits of standardization. Yes, you can statically compile a binary, but with a containerized app, you have a standardized deployment unit for any technology not just those that compile to a single binary. Also you have the flexibility to deploy and configure a mix of containers on a pool of hardware all with central control and management of infrastructure its supporting services.
Disagree. I've been on both sides of those choices, and the containerized deployment infrastructure is much nicer to work with, as a software developer. And I think it is less annoying for ops folks too, but I'm less sure about that.
"Containers have revolutionized software development by providing a very efficient path to take software written by developers and run it in production in a matter of minutes or hours, rather than days or months using traditional approaches."
FUD. The technology of deployment does not change 'minutes or hours' into 'days or months' - it's management red tape that does that. In fact, in my use case, Docker takes a similar time to build as a normal package (.deb) using an up-to-date base image, but is actually slower to deploy, since now my servers have to download a stupidly large container with build-essential (npm doesn't really survive without it), python (because npm maintainers use python frequently), and graphicsmagick (for the in-house app), instead of 'just the app' that's in a normal package.
If your environment is simple enough that you don't have to be concerned with testing in 'staging' against staging databases or similar, then you're definitely not saving 'days', because your env just isn't that complicated.
I’m not sure I made that comparison. I’m saying the popularity of containers is an existence proof that the distro-oriented shared library system is failing to meet the needs of common use cases.
Programs that bundle dependencies have a radically reduced need for snapshots, VMs, or containers. Such tools do provide a variety of value. But they don’t become virtually requirements to merely launch a program without error.
Ship your damn dependencies says I. Either statically or dynamically, but ship them.
In practice, I think the analogy holds up. A sizable chunk of use cases for containerization is to confer the benefits of standalone executableness, which is similar to a sizable chunk of use cases for statically linked binaries.
I won't advocate for setting up all development to happen inside containers, but delivering software with containers is an order of magnitude simpler than delivering to a running os.
You need packaging, update scripts, init scripts and strict policies for upgrades and do coordinated library updates (on the shared environment), or nearly roll your own os where you bundle your dependency with the app. That is incredibly time consuming.
With containers you don't need init scripts, the team can update any dependency when they want/need without breaking someone elses environment. And with containers every team deliver the same 'thing', a runnable image. Not a blob of php, some ruby and java ear and wars that have to run on a shared platform.
That's one of the main touted benefits of containers (a.k.a build reproducibility). You can view containers as a an overly complicated way to make software with complicated deployment brain-dead easy to deploy.
We're at the point in the hype cycle where it starts getting fashionable to dismiss that as an overkill, but the reality for most of us out there is that most software is way more complicated than a single executable and containers make it easier to deploy complicated software.
Just spit balling ideas here, how much of the problems containerizing is meant to solve would be solved by merely static linking? Because it feels like that's what containers are mostly used for. Static linking + a sandbox to get most of everything.
Using shared libraries but then shipping the .so's in a container defeats the point of a .so in the first place. If the reason containers are okay now since disk space is cheap, why not return to static linking of executables?
I've seen containerized applications described as "statically linked apps", it's one blob with dependencies included. I'm moving in that direction (vs cap-style deployments) because it guarantees that all machines are identical (from QA to staging, to production). Spinning up additional machines becomes trivial.
reply