What if there's another software in another language you want to interoperate with? What if you want to avoid containers with their complexity and dubious security record?
The best formulation I saw is "containers are a solution to the Rube Goldberg Machine development pattern".
Since dependency resolution problems are hard for many popular languages (Node, Python, Ruby), you are not going to enjoy sharing the installed packages between two apps. Same with shared libraries for compiled languages.
Otherwise something like Nix + cgroups-based runner had a chance to suffice.
There is a lot of infrastructure around security and availability that isn't yet achiveable with off the shelf software. So ideally you use containers to define dependencies and deployment, and deploy into a proper environment.
That's a very basic example. Let's say your program also depends on ffmpeg to convert some images, psql to interact with a database and a few other non-library dependencies.
With containers you can trivially ensure those are always present and with the correct versions.
Plus containers do give you some security benefits when compared to running natively.
Sounds like containers could be OS built-in for non-cli applications? Any app can be containerized so that adds a level of isolation and security. I actually use containers whenever I can so I don't worry about left over garbage.
Agree 100%. In addition to language frameworks, as you say, you also have orchestration, application definition, failover, storage persistence, etc. services that can be made largely portable between providers. Containers, while probably not necessary, likely help by letting you decompose things and package them up in a way that you can move them between providers.
Oh, I love containers and do most my work in them. However I also mind that that production needs are different than developer needs and have seen too many cases where containers made security audits (a new openssl update - where do I have to apply it?) hard ... and certificates triggered me ;)
Your application is already most likely a big binary blob of uncertain origin that's hard to reproduce. Containers allow these big binary blobs of uncertainty to at least be protected from each other.
You probably know this, but you'll gain a lot of performance by building native containers. In most cases it's trivial as long as the software builds on arm64 or can be crosscompiled.
Containers are cool for big things. But imagine every single program stuck inside a container without proper management tools to track dependencies. Now imagine a heartbleed-like scenario where you need to patch a big security hole ASAP. With containers you'd have a hard time.
Once you have a hammer… One advantage of software containers is to have this unique interface that is the same whatever is inside the container. Like shipping containers.
If it's one single golang binary, or a weird python container running only on specific version of Debian compiled during a blue moon, or some 8GB java enterprise bloatware, it's the same.
You’re not wrong but containerization is pragmatic - not idealistic. You can still write simple, clean software packaged in a SCRATCH container - but you can also isolate whatever crap you have to work with the get the job done. Both the elegant app and the horrible one now share a reliable init system.
This makes me think of Docker containers but for desktop rather than server use. Let the language/stack be Elixir/Phoenix if that's what the devs want to use; as long as I can pull down an app container that runs on my machine then the need to rely on a least-common-denominator language goes away and we're all better off.
This is why we need packaging standards, especially around metadata, instead of further decamping into language-specific ecosystems. Because even with containerized apps, you still want a few launch scripts and a compiled program (for instance) that might contain multiple dependencies from different languages (C, Go, and Fortran, maybe).
Even a statically linked program can have dependencies on the system it’s running on, like system fonts and root certificates. Containers ensure a standard environment that accounts for those differences, in a language-agnostic way.
> Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources).
Ultimately there's no reason why containerization can't be pushed right down to the language level. Consider .NET's AppDomains, or even further, a capability-secure programming language which isolates at the object level with zero overhead over ordinary languages.
Containers are powerful because they solve many computing issues, one of which being able to act as a (lower case c) static container for dynamically linked apps as well as cross-language, multi-executable meta-apps.
Containers also provide many forms of isolation (network, file system etc.), they provide a modern versioning and distribution scheme, composibility (use another container as a base image).
All of these things can, and perhaps should be, done at a the language level as well but containers also work across languages, across linking paradigms, and with existing binaries.
reply