Hacker News new | ask | show | jobs
by teacup50 4236 days ago
In this case, the problem isn't being solved -- solving the problem would mean moving away from dependencies on the global OS namespace by relearning how to write self-contained applications (some people never forgot).

Containers are just a big wad of duct tape holding together the ball of mud that comprises most web applications' server-side components.

Add containers, and you haven't solved the problem, you've just made two problems.

2 comments

It's great for those nasty legacy apps that only work on old unmaintained versions of Rails or old OS Versions etc.

Take all the nastiness and throw it into a box, without needing to contact Ops to reserve memory and provision a VM.

IMO, it's one of the major reasons why Enterprises get so excited about Docker. Legacy app dependency issues are horrible once you get past a certain scale.

VM's are expensive and non-self-service at most orgs since they tie up RAM and licenses.

Functions are just a big wad of duct tape holding together the ball of mud that comprises most applications' lines of code. Add functions, and you haven't solved the problem, you've just made two problems.

Does this sound true to you? What makes containers any different from the organization that the abstraction of "functions" bring to ordinary sequential programs?

Containers abstract over reducible complexity.

Functions (should) abstract over irreducible complexity.

As long as we're asking hypotheticals — why do applications need to control the global OS namespace and the dependencies between elements in that namespace to a degree that the applications themselves can't be easily deployed without containers?

Can that problem be reduced?

If not, why not?