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.
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.
> The promise behind software containers is essentially the same. Instead of shipping around a full operating system and your software (and maybe the software that your software depends on), you simply pack your code and its dependencies into a container that can then run anywhere — and because they are usually pretty small, you can pack lots of containers onto a single computer.
Already got it wrong. Current containers are exactly the OS and the kitchen sink for running 'printf("hello world")'.
Exactly, container is a way to package all these disorganised, chaotic snowflake languages into something you can actually run in a standard way.
It full fills the function of an executable, but at a higher level of abstraction. We've come full circle again.
Although I'm not sure I would use this, this is the kind of stuff I've been waiting for. Where nice clean containers are used as part of an active dev cycle rather than just the production push.
The ultimate dream of the end user using a desktop comprising only of containers seems to be still a bit far off yet...
I think we've seen a proliferation of one concept, often disguised as many things: the container for a program.
A long time ago, the program was your whole OS, you'd boot into it. The computer is the container.
Then we introduced operating systems, allowing a safer container for bad programs. The program is the container.
One type of program became extremely popular because it enabled delivery of a program via the internet. The web app is the container.
In the web world, frameworks like React have become incredibly popular because they allow people to break up apps into smaller components that can be shared. The component is the container.
Of course, on the back end, similar needs have led to Docker/K8s. The container is the container.
Given that everything in our world is a container, you'd think we would have better tools for composing them. As a web developer, I should be able to embed other web apps and communicate with them like I do with my React components. And I'd also like to be able to boot directly into a web app, and embed native programs and virtual operating systems.
Even when it comes to basics: most operating systems other than Chrome still have yet to natively support the web as a peer of traditional programs.. Electron should't be necessary. Likewise, environments like Docker and VirtualBox should be baked in to the OS that we boot.
The point is, as an industry we need to collectively pull our heads out of our asses, and realize that we'd be much better off refactoring our magnificent existing containers, rather than attempting to invent new ones. (I'm looking at you, iOS/Android..)
Containers are often touted is this novel concept that's bound to revolutionise software development and software delivery in particular.
The general idea isn't all that new however. Java Applications have been delivered as containers since 1995 (although the concept isn't explicitly named that way with Java applications).
Each JAR / WAR is a self-contained application that can run anywhere where there's a JVM (which is pretty much everywhere).
From a feature perspective the only real innovation of Docker-style containers probably is that those aren't limited to the JVM but are (largely) language- and runtime-agnostic.
That sounds really interesting, and I'd love to learn more about this. Did you hack something together yourself to allow you to do this, or are you using some software to manage the containers for you?
I always felt, perhaps uncharitably, that the point of containers was "those other programmers are idiots so we need to encapsulate everything for the sake of defense"
> That said, think about what a container (e.g. docker) is. A running container is kind of like a packaged executable, except it also has a filesystem.
> So if you pack data (which can be modified and runtime!) into a container, it's a similar concept to an embedded resource in an executable, except it can change.
> Now, in a container, any changes made to data at runtime inside the container won't persist unless the container is given persistent storage.
> What I've been wondering lately is why we didn't invent some kind of single "executable plus volatile data space embedded within the executable", so that programs and data (say, a database) could couple together into a single file.
Things like this have existed before, and I presume still exist. For instance, before MacOS X, applications for Macintosh for (vaguely) similar to "application bundles. Leaving aside the technical differences of implementation, classic Macintosh applications had a "resource" store that included code and 'static' data (pictures, text, whatever) but could be modified by running program. Changes could be persisted without using any other files. In practice, changes were often persisted elsewhere, be cause if a fault occurred during modification, the executable could be corrupted, and because this made things like resetting to defaults easier (by deleting or moving an external preferences file, for example).
reply