Live data from Hacker News

Why Docker Is Not Yet Succeeding Widely in Production

sirupsen.com

201–210 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#201

I think the author missed orchestration. docker-swarm/docker-machine is still not production ready and kubernetes is too damn complicated to setup outside GCE

(acknowledgement, I'm a contributor to Kubernetes)

It is well supported on AWS as well, and a variety of bare-metal solutions (e.g. Red Hat Atomic, CoreOS)

However, concretely, it is a challenge to maintain good support for N different platforms without an owner who is willing to stand up and ensure that it works, and continues to work for that platform.

We have gotten a number of drive-by contributions of "how to" guides that (sadly) bit-rot over time. As always, we're working on improving the situation, but it is complicated and requires a great deal of time and access to infrastructure (e.g. Rackspace) that the core team simply doesn't have.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#202

I think the author missed orchestration. docker-swarm/docker-machine is still not production ready and kubernetes is too damn complicated to setup outside GCE

(acknowledgement, I'm a contributor to Kubernetes) It is well supported on AWS as well, and a variety of bare-metal solutions (e.g. Red Hat Atomic, CoreOS) However, concretely, it is a challenge to maintain good support for N different platforms without an owner who is willing to stand up and ensure that it works, and continues to work for that platform. We have gotten a number of drive-by contributions of "how to" g…

(which is a long-winded way of saying: PRs welcome, please help us make it better ;)

Re: Why Docker Is Not Yet Succeeding Widely in Production

#203
post #160

My application compiles to a jar that runs on a server and expects an accompanying config file. I've tried giving Docker a whirl a few times and I never fully understood what need I had that it was solving.

Is your application just a jar? In the yes case your conclusion is correct. Throw in a database, a cache server, couple of versioned libraries your jar file needs, and more developers, and suddenly a reproducible image with all this packaged will make a lot of sense.

Our build process already includes the application's dependencies inside the jar, and packages it into an installable deb file that places the app, its config, and the init file in the right locations.

I have a database and a cache server. They don't run on the same server as the application jar... they run on separate machines tuned to their purpose. Why would I want them packaged together? So my team doesn't have to run "apt-get install postgresql" on their dev machines? Or to maintain an exactly consistent dev environment?

Re: Why Docker Is Not Yet Succeeding Widely in Production

#204

I think the author missed orchestration. docker-swarm/docker-machine is still not production ready and kubernetes is too damn complicated to setup outside GCE

(acknowledgement, I'm a contributor to Kubernetes) It is well supported on AWS as well, and a variety of bare-metal solutions (e.g. Red Hat Atomic, CoreOS) However, concretely, it is a challenge to maintain good support for N different platforms without an owner who is willing to stand up and ensure that it works, and continues to work for that platform. We have gotten a number of drive-by contributions of "how to" g…

completely understand. hopefully I'll get well-versed enough with heat to contribute

Re: Why Docker Is Not Yet Succeeding Widely in Production

#205

I think the reason is because the tooling and the companies (CoreOS, Joyent, Weave, etc.) building all of the tools, are only focusing on grabbing Fortune 500 customers. Nobody is building Docker tools for the "Blue Collar Apps" of the world. And those companies might be completely justified because the benefits of Docker versus Amazon AMIs/RPMs/DEBs/etc. aren't that big enough to make us go crazy for Docker and swit…

> Fortune 500 customers

Fortune 500 technology customers. Fortune 500 companies who have hundreds of millions and decades of work invested in their infrastructure generally aren't going to jump on whatever the latest infrastructure trend is.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#206
post #136

Earlier quoted context omitted.

I have mixed feelings about Docker. I've found three major use cases so far: (1) Testing. (2) Build environments -- it's helpful to build distribution Linux binaries in older Linux versions like CentOS 6 so that they'll work on a wider range of production systems. (3) Installing and running "big ball of mud" applications that want to drag in forty libraries, three different databases, memcached, and require a custom…

>Docker might still be nice for perfect reproducibility Docker actually doesn't help reproducibility at all, because the underlying reproducibility problems present in the distro and build systems are used are still present. See GNU Guix, Nix, and Debian's Reproducible Builds project for efforts to make build truly reproducible. I had a good laugh when I read "the Rube Goldberg Machine development anti-pattern". This…

Nothing wrong with linking together a couple things to build an app... I call it Rube Goldberg (a.k.a. ball of mud, pile of crap, etc.) when it's like dozens of things that all have to be tweaked in exactly a certain way or everything assplodes.

I simply will not run apps like that unless I have no choice. If I see that, plonk it goes into the trash.

... and yes, the whole package management situation is comical. Every language has its own package management system, and the OS, and sometimes people use both at the same time. It's ridiculous.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#207
post #157

Earlier quoted context omitted.

> is that if it ain't broke, don't fix it. I hate being passive-aggressive so I'll be directly aggresive here: this mentality is a way to say, "I don't want to revisit the operational aspects of my system because I don't like to do that work. Find someone else." Like any aspect of your system, your ops and deploy components can rot. Pretending otherwise is outright ignoring a consistent lesson offered by those who ca…

I had a very smooth workflow on Python/Django/AWS. Thought of checking out Dockers for the last project and boy did that hurt! "if it ain't broken, don't fix it" is very appropriate here. I would suggest that until you've huge issues with deployment, skip dockers. For me, it added loads of work instead of simplifying the flow.

How does Python/Django deploy itself to AWS?

Last time I checked, Python and Django are agnostic to their operational concerns and deployment.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#208

I think the author missed orchestration. docker-swarm/docker-machine is still not production ready and kubernetes is too damn complicated to setup outside GCE

Speaking mainly from experience, kubernetes isn't that hard to get set up. Unfortunately the documentation tries hard to convince you otherwise.

Leading up to Kubernetes v1, getting set up was quite painful but the api is now stable. So now I have an environment running Kafka, Cassandra, Spark and various java based services and am quite happy with it so far.

I've started using the hawtio kubernetes console to visualise my containers but may write my own tool to do this. I might also write a blog post detailing how to install, configure pods, expose a service and use the logs to diagnose problems. It's usually the first thing you'd want to know when starting out sound of GCE infrastructure.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#209

While the article goes into the more technical reasons for not using Docker in production, the practical reason "Why Docker Is Not Yet Succeeding Widely in Production" is that if it ain't broke, don't fix it. The advantages of Docker do not necessarily outweigh the opportunity cost of rewriting the startup's entire infrastructure. Docker will likely be more prevalent in a few years with startups who have built their…

New startup. Did not use docker. Happy with scripts and ansible.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#210
Docker is part of the first generation of a good idea - containerization. The problem is that there's too much stuff in the box. Each application doesn't need its very own copy of everything. You get portability at the expense of maintaining your own distro. There will be a second generation of this, hopefully not so bulky.
Post reply on HN