Hacker News new | ask | show | jobs
by scurvy 3981 days ago
I still haven't been sold on Docker. Why would an otherwise competent company that runs things just fine, ditch it all and adopt Docker? Just because it's the shiny new thing? What do we actually gain here in production?
3 comments

Because "running things just fine" across production, continuous integration and on dev machines is actually quite a hard thing to do.

But then, if you don't feel like you need it, that's probably because you don't need it.

(If people are downvoting your question, it's probably because you're giving off a bit of a "I don't understand Docker so it must be crap" vibe, which is not helpful.)

OK, now we're getting somewhere. What is difficult about getting things right across production and CI? What are the pain points? What are the exact problems we're being asked to solve here? I don't think dev environments need to be harmonized the same as production. If your tests are good, you should catch most of the "it worked on my laptop" problems.

Sorry if my initial question came across with a weird vibe. I'm generally curious. I have colleagues working at places and they actually are being asked to drop everything and implement Docker. I asked why and what's driving this and got the predictable response of "management/dev/someone wants something new".

Most "it worked on my laptop" problems get caught somewhere between commit and push to production. What docker helps with is catching them "early" rather than "later". Because a failed push emergency push with reason "Doesn't work in production environment" as a reason is a really stressful way to work.

Catching it before pushing your changes is far more preferable.

There are a lot of different methods and processes to fix this. Docker is a new one that simplifies a number of the pieces of the puzzle by constraining the environment is useful ways.

However, if you already have a process worked out and aren't experiencing pain then you probably don't need to switch for the sake of switching.

> I don't think dev environments need to be harmonized the same as production. If your tests are good, you should catch most of the "it worked on my laptop" problems.

That's true until something break in production: then you want to replicate the same situation in the dev environment, as close as possible.

Please take note of the companies that are using docker.

Docker isn't magical, but the process that it lends itself to can be very useful. Those companies aren't using docker to be successful. They are successful because of the processes (and intensity) that docker fits into.

I'm sorry that your colleagues are being asked to drop everything and look at anything (much less Docker). That's not a nice way to work -- and I'm sure it influences their notions of Docker.

containers provide a reasonable level of abstraction/isolation for applications, and have been used in production for some years now. Docker may be shiny, but containers not so much.
But why the need for abstraction and isolation? If I'm a reasonably well run web shop that knows how to run their apps and balance out server load, what does Docker get me?

Also, shout out to the fanboys for downvoting my question, which was just a question asking for thoughts and answers and didn't make any statement whatsoever.

@mateuszf can you give actual examples of each? I can upgrade nginx on my servers without affecting memcache or MySQL or redis or....Why the need for isolation there?
Docker is a tool to empower developers to better manage the applications that we currently leave to people who, and I'm trying to be charitable here, seem to think knowing how to type and be rigid in their opinions is some kind of qualification for managing systems.

It has literally nothing to do with the ability to upgrade independent pieces on the sysadmin's schedule and everything to do with abstracting sysadmins clean out of the process. The entire profession has established itself as a roadblock to progress, so like good engineers do, we're busy coding the problem away.

Basically.

Isolation - so you can run / snapshot / restore multiple applications not influencing each other on one machine. Abstractions so that you code doesn't have to worry about different os-es, cloud providers, etc.