Comment by grosswait
2 hours ago
> No I didn't say that, I think you suffer from the curse of having a lot of previous experience in an adjacent area where you built a strong mental model of how things ought to work, but now you're trying to forcefully apply this same mental model onto Docker. I think you just proved his point. Docker came onto the scene and hit roadblocks in enterprises where sysadmins lived. These architectural and terminology choices ran head on into well established domains. Yes, docker did change things, but I think his point is it would’ve had more success with paying customers if the authors of docker had a better understanding of established network administration and system administration concepts from the start (though these were the early devops days…). That lack of understanding caused adoption friction in enterprise space, and different choices could’ve prevented that without changing at all the paradigm of what docker is.
The docker mental model isn’t crazy different. Design choices made it unnecessarily less compatible with existing mental models. This probably contributed to the feeling of it being revolutionary, but impeded its adoption with paying customers.
Can you be more concrete?
In my experience adoption was primarily driven by developers and sacrificing clarity would hurt adoption. This perfect familiarity was never achievable anyhow. Docker was a completely new paradigm in software development, similar to how modern cars aren't just horse carriages without the horse. It transformed everything from development, testing, deployment, updates.
Experienced sysadmins often tried to approach it with "VMs but with less overhead" mentality, which couldn't possibly work. Coworkers would ask me how they can install SSH daemons in containers to update packages and view logs, or they would refuse to adopt Dockerfiles, sometimes setting up the container manually and exporting the image. They would wonder how to install many different services in 1 container and handle crashes, etc. It was a huge shift.
> Design choices made it unnecessarily less compatible with existing mental models.
Again, I disagree. Whose mental model do you prioritize? How invested are you in making Docker work just like whatever elaborate system those enterprise admins used before?
Let's not forget that by creating new abstractions, you're penalizing users who already possess foundational knowledge of the primitives. If you do this then I'm probably going to get a whiff that you care more about enterprise sales than developer experience (duh) which is a huge red flag for me.