Hacker News new | ask | show | jobs
by derefr 4464 days ago
Whether something is or is not "production-ready" is subjective. Different projects can handle different levels of (un)reliability; "production-ready" really just means "not a significant contributor to your service's downtime, relative to the quality of your own code."

A more useful-and-objective piece of information, I think, would be the average/maximum number-of-nines of reliablity reported by current users of the project. Then you could just look at your own project's current reliability, and allow yourself to depend on anything more reliable than you are.
1 comments
keule 4463 days ago
Oh I am not disagreeing with you on that one. Definitely a subjective matter. Just the statement about "production-readyness" of docker comes from the docker developers themselves.
link
derefr 4463 days ago
Humility is often a problem with software developers, though. Some software is still versioned 0.X after ten years of development, releases, adoption and usage. I would take any developer's claim that their software isn't production-ready with a grain of salt, and test it for your use-case for yourself.

They are probably correct-enough in that you shouldn't be using Docker in production at Google/Amazon/Facebook/wherever. It's not yet nine-nines reliable. But Docker is probably more reliable than your startup's MVP, and you shouldn't let "not production-ready" scare you away from developing and shipping your new project using Docker.

link
keule 4463 days ago
Yes. I did use systems in the past that had questionable versioning, milestone releases a.s.o. and they proved to be just fine. Docker on the other hand is not just a third-party library in your project.

Docker is a container, and I therefore apply the same set of standards that my linux distribution/kernel should fullfill.

link
derefr 4463 days ago
> Docker on the other hand is not just a third-party library in your project. Docker is a container

What's the difference, exactly? In either case, a failure in the code composing the third-party component can, at worst, cause an instance of your application to crash and corrupt state, preventing instances on that machine from coming back up.

But as long as you've got immutable deployments[1] set up, when all else fails, you can just destroy the server (hosting the containers) hosting your app instances, and deploy it afresh, which should be automated to the point that it only takes a few minutes.

[1] http://chadfowler.com/blog/2013/06/23/immutable-deployments/

link
bjt 4463 days ago
When talking about whether something like Docker is production-ready, the "at worst" can be a lot worse than that, particularly where security is concerned. Months back they found that Docker's API wasn't sufficiently locked down, for example, and could be accessed by an untrusted process. So they changed that and locked it down.

I don't see anything unreasonable about waiting to use a package until the devs themselves say it's "production ready".

link