His principal complaint didn’t seem to be boot time, but rather architectural complexity. But I agree with you—unless egregious, boot time isn’t a huge factor for most companies.
The article appears to mostly hinge upon the assumption that Docker is being used primarily as a sandbox, which to me seems like a weird assumption to make. I found it odd that this caveat wasn’t immediately made clear in the article’s headline, since I suppose this is at odds with what most folks would want to use container technology for.
The kernel namespacing and isolation features are convenient when implementing a technology aimed to deliver and host services, but I doubt the overall design of Docker would have been much different if those facilities had never existed. We’d still want to provision and distribute images just the same.
While faster boot time is rarely a bad thing, for many use cases, with somewhat long running tasks, it doesn’t matter as much. See JVM.
His principal complaint didn’t seem to be boot time, but rather architectural complexity. But I agree with you—unless egregious, boot time isn’t a huge factor for most companies.
The article appears to mostly hinge upon the assumption that Docker is being used primarily as a sandbox, which to me seems like a weird assumption to make. I found it odd that this caveat wasn’t immediately made clear in the article’s headline, since I suppose this is at odds with what most folks would want to use container technology for.
The kernel namespacing and isolation features are convenient when implementing a technology aimed to deliver and host services, but I doubt the overall design of Docker would have been much different if those facilities had never existed. We’d still want to provision and distribute images just the same.
TIL, I thought docker (and pretty much any other container runtime) was built around
unshare(2), notclone(2)