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.
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.
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.
Does this sound true to you? What makes containers any different from the organization that the abstraction of "functions" bring to ordinary sequential programs?
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?