3 ms·

Is the docker/container model supposed to be all things to all people? I don't think so. Containers are a building block that let us handle one concern. They a

by mfer 6y ago

Is the docker/container model supposed to be all things to all people? I don't think so. Containers are a building block that let us handle one concern. They are a great tool for some things. But, to expect the app dev concern of "just run my code" to be solved by them well is missing the other concern. I think Docker does some things well. I think this works as intended. I just think that we need other things that use these building blocks better to create better solutions at the right level of abstraction.

ethbr0 6y ago
That feels like an abrogation of responsibility. At this point in computing system complexity, secure defaults over configuration is a requirement for a sane system. As we increasingly convert infrastructure into code, this means infrastructure configuration requires secure defaults as well. That the Docker ecosystem doesn't seem overlying concerned (as a core, drop-everything, #1 priority) about a decades-hard security problem (detecting and resolving insecure dependencies) seems shortsighted. To put it another way, there are two realities: (A) No tooling support is provided to address a risk efficiently and quickly = no one addresses the risk (B) Efficient, effective tooling is built, maintained as platform evolves, and advertised to the community = everyone does what they should I realize the structure of Docker dissuades them from actually addressing (B), but it seems like an existential threat to adoption.
- mfer 6y ago
  > That feels like an abrogation of responsibility. How often are people who deal with OS packages working on kernel level vulnerabilities or are dealing with microcode for CPUs? If someone is working on libc or libcurl are they supposed to follow and track all of the kernel level issues for every place the code would run? I would argue that someone working on libcurl is working at a different layer in the stack than someone working on a kernel. libcurl can run on multiple kernels. The same idea of layers is true when you're talking about someone working on a nodejs app and those OS layers. > To put it another way, there are two realities: > (A) No tooling support is provided to address a risk efficiently and quickly = no one addresses the risk > (B) Efficient, effective tooling is built, maintained as platform evolves, and advertised to the community = everyone does what they should I think Kelsey Hightower said it best when he said that Kubernetes is a platform for building platforms. I would argue that container systems in general are platforms for building platforms. I know people who spend a bunch of time building a platform on top of k8s at different companies. Yet, in these conversation we keep coming back to Docker or container platforms as being the platform that app developers _should_ interact with. App devs speaking out, people like Kelsey speaking up, and security issues like this all say that maybe that _should_ is wrong.

by mfer 6y ago

ethbr0 6y ago

That feels like an abrogation of responsibility. At this point in computing system complexity, secure defaults over configuration is a requirement for a sane system. As we increasingly convert infrastructure into code, this means infrastructure configuration requires secure defaults as well. That the Docker ecosystem doesn't seem overlying concerned (as a core, drop-everything, #1 priority) about a decades-hard security problem (detecting and resolving insecure dependencies) seems shortsighted. To put it another way, there are two realities: (A) No tooling support is provided to address a risk efficiently and quickly = no one addresses the risk (B) Efficient, effective tooling is built, maintained as platform evolves, and advertised to the community = everyone does what they should I realize the structure of Docker dissuades them from actually addressing (B), but it seems like an existential threat to adoption.

mfer 6y ago
> That feels like an abrogation of responsibility. How often are people who deal with OS packages working on kernel level vulnerabilities or are dealing with microcode for CPUs? If someone is working on libc or libcurl are they supposed to follow and track all of the kernel level issues for every place the code would run? I would argue that someone working on libcurl is working at a different layer in the stack than someone working on a kernel. libcurl can run on multiple kernels. The same idea of layers is true when you're talking about someone working on a nodejs app and those OS layers. > To put it another way, there are two realities: > (A) No tooling support is provided to address a risk efficiently and quickly = no one addresses the risk > (B) Efficient, effective tooling is built, maintained as platform evolves, and advertised to the community = everyone does what they should I think Kelsey Hightower said it best when he said that Kubernetes is a platform for building platforms. I would argue that container systems in general are platforms for building platforms. I know people who spend a bunch of time building a platform on top of k8s at different companies. Yet, in these conversation we keep coming back to Docker or container platforms as being the platform that app developers _should_ interact with. App devs speaking out, people like Kelsey speaking up, and security issues like this all say that maybe that _should_ is wrong.