[hiou]

I hate to say it but this article sounds like it was written by your typical one trick pony, technology averse client services agency.

They are the last to adopt new things as they tend to be the lowest on the talent chain as meeting estimates, often via client coercion or moving goalposts, is much more important than successful solutions over the mid-ling term.

For anyone reading this that is part of that group, leave stuff like containers to outside organizations with stronger engineering talent and focus on what ultimate makes you money which is client networking and sales.

[swap32]

>> written by your typical one trick pony, technology averse client services agency.

You can be forgiven to have that perception. Sorry, but that's not true.

>> They are the last to adopt new things

Are you actually complaining about this? Well it just shows your immaturity as an engineer and your lack of understanding of how tech startups are run. This is something my very first manager drilled into me on my first job a decade ago, as should yours have - not to use any v1.0 software for ANY CLIENT PROJECT, but only for your hobby projects. Wait atleast for a v1.1

>> as they tend to be the lowest on the talent chain as meeting estimates

Please don't embarrass yourself. There are comments on this thread from the maintainers of both docker and kubernetes projects as well as people who have been running docker in production for much longer than us. None of them think that this article is stupid. Now, if you think you're more talented than us and all of them combined, just tell us why?

Your comments would be much more useful if you could say something like - "They are so stupid because they couldn't figure out X which was as easy as doing Y."

[hiou]

Anytime you want to go toe to toe let me know. Being cheaper and more predictable is so different from actually having to make the best possible product.

[fapjacks]

This is absolutely the truth. Docker isn't something you can get an afternoon briefing on in a meeting room and then kinda wing it on implementation. How much you actually read the documentation will be immediately and plainly obvious and inversely proportional to the amount of problems you run into.

[swap32]

>> afternoon briefing on in a meeting room and then kinda wing it on implementation

I don't know where did you get that impression from. The article clearly states we ran docker in PRODUCTION for 6 months. The article wasn't written after a docker trial over a weekend.

>> How much you actually read the documentation will be immediately and plainly obvious and inversely proportional to the amount of problems you run into.

Pretty much everyone who's commented here and have had docker experience in production, agrees that a docker documentation sucks. Maintainers of the dockers project have already conceded that this is an issue so I don't why you're saying this.

[fapjacks]

That you're making this claim is an almost comically ironic indicator to me that you are exactly what was described.