Hacker News Reader

Comment by ianburrell | Hacker News Reader

I suspect that containers would have taken off even without isolation. I think the important innovation of Docker was the image. It let people deploy consistent version of their software or download outside software.

All of the hassle of installing things was in the Dockerfile, and it was run in containers so more reliable.

View on HN

I honestly think that Dockerfile was the biggest driver. Containers as a technology are useful, for the many reasons outlined in this thread. But what Dockerfiles achieved was to make the technology accessible to much wider and much less technically deep audience. The syntax is easy to follow, the vocabulary available for the DSL is limited, and the results are immediately usable.

Oh, and the layer caching made iterative development with _very_ rapid cycles possible. That lowered the bar for entry and raised the floor for everyone to get going easier.

But back to Dockerfiles. The configuration language used made it possible for anyone[tm] to build a container image, to ship a container image and to run the container. Fire-and-forget style. (Operating the things in practice and at any scale was left as an exercise for the reader.)

And because Anyone[tm] could do it, pretty much anyone did. For good and ill alike.

I agree: I think the container image is what matters. As it turns out, getting more (or less) isolation given that image format is not a very hard problem.

> I think the important innovation of Docker was the image. It let people deploy consistent version of their software or download outside software.

What did it let people do that they couldn't already do with static linking?

I can't tell if this is a genuine question or not but if it is.. deploying a Ruby on Rails app with a pile of gems that have c deps isn't fixed with static linking. This is true for python and node and probably other things I'm not thinking of.

- most languages don't really do static linking in the same way as C

- things like "a network port" can also be a dependency, but can't be "linked". And so on for all sorts of software that expects particular files to be in particular places, or requires deploying multiple communicating executables

- Linux requires that you be root to open a port below 1024, a security disaster

- some dependencies really do not like being statically linked (this includes the GNU standard library!), for things like nsswitch

Because it doesn’t need you to delve deep into the build system of every dependency and application you ever want to package?

>> It let people deploy consistent version of their software

Surprisingly "my software" depends on a lot of other stuff. Python, Ruby, PHP, JS, etc all need tens to hundreds of native libraries that have to be deployed.