11 ms·

I think there were multiple reasons why containers started to gain traction. If you ask 3 people why they started using containers, you're likely to get 4 answe

I think there were multiple reasons why containers started to gain traction. If you ask 3 people why they started using containers, you're likely to get 4 answers. For me, it was avoiding dependencies and making it easier to deploy programs (not services) to different servers w/o needing to install dependencies. I seem to remember a meetup in SF around 2013 where Docker (was it still dotCloud back then?) was describing a primary use-case was easier deployment of services. I'm sure for someone else, it was deployment/coordination of related services.

dabockster 1y ago
The big selling points for me were what you said about simplifying deployments, but also the fact that a container uses significantly less resource overhead than a full blown virtual machine. Containers really only work if your code works in user space and doesn't need anything super low level (eg TCP network stack), but as long as you stay in user space it's amazing.
fragmede 1y ago
"making it easier to deploy" is a rather... clinical description for fixing the "but it works on my machine!" issue. We could go into detail on how it solved that, but imo it comes down to that.
- yen223 1y ago
  There's a classic joke where it turns out the solution to "it works on my machine" was to ship my machine
misnome 1y ago
The main initial drive for me was that it let me separately run many things without a) trying to manage separate dependency sets, and b) Sharing RAM - Without having to physically allocate large amounts of memory to virtual machines; on an 8GB machine at a couple per VM that doesn’t let you get far.
agumonkey 1y ago
my view of docker, as a who thought it was a shallow wrapper on linux namespaces, is that it was a good fit for the average IT shop to solve the deployment friction no more handmade scripts(or worse fully manual operations) stupid simple dockerfile scripts.. any employee would be able to understand and groups can organize around it docker-compose tying services into their own subnet was really a cool thing though
- MonaroVXR 1y ago
  Still not the case, today anyone would understand them. At least in this part of the country where I live

dabockster 1y ago

The big selling points for me were what you said about simplifying deployments, but also the fact that a container uses significantly less resource overhead than a full blown virtual machine. Containers really only work if your code works in user space and doesn't need anything super low level (eg TCP network stack), but as long as you stay in user space it's amazing.

fragmede 1y ago

"making it easier to deploy" is a rather... clinical description for fixing the "but it works on my machine!" issue. We could go into detail on how it solved that, but imo it comes down to that.

yen223 1y ago
There's a classic joke where it turns out the solution to "it works on my machine" was to ship my machine

misnome 1y ago

The main initial drive for me was that it let me separately run many things without a) trying to manage separate dependency sets, and b) Sharing RAM - Without having to physically allocate large amounts of memory to virtual machines; on an 8GB machine at a couple per VM that doesn’t let you get far.

agumonkey 1y ago

my view of docker, as a who thought it was a shallow wrapper on linux namespaces, is that it was a good fit for the average IT shop to solve the deployment friction no more handmade scripts(or worse fully manual operations) stupid simple dockerfile scripts.. any employee would be able to understand and groups can organize around it docker-compose tying services into their own subnet was really a cool thing though

MonaroVXR 1y ago
Still not the case, today anyone would understand them. At least in this part of the country where I live