But that's actually the industry containers are good for. Enterprise. Predictability trumps costs. The flaws of docker may over time get fixed. It's the small companies and startups that are making a fool of themselves by pretending they extract any kind of value out of docker.
Imagine a large 100+ man software project that spans two years and involves four different organisations collaborating. There are at least 100+ non-technical 'knowledge workers' interacting with this process. The people have the intent of 'not being responsible for anything', but establishing their position/role so their cost/budget is validated. You know, the typical large-scale Oracle/Cap-Gemini/IBM clusterfuck of incompetence.
But that's the secret! They aren't incompetent at all (as organisations). They sell something no-one else sells. They sell predictability.
Because for all what it's worth: they don't make huge architectural fuck ups. They make their deadline. And they are able to deliver something, even with this many stakeholders pissing all over the project from any direction.
For them, docker is brilliant. It standardizes something. It doesn't do it very well, but that doesn't matter. They aren't in a low-margin world. "Docker isn't really secure, you really should run every docker image in a separate VM". Sure. These sort of people are paying 500-1000 per instance anyway. No one cares. Coordinating devops with this many stakeholders, now _thats_ expensive.
The quality of the actual technology (much like on the web itself) is initially irrelevant. The value is in the fact there's a contract. A standard. Docker is a bad implementation of reasonable idea. The question isn't if it's a good technical choice. No, it's not. But it's organisational and economically more compatible with the rest of world.
And you know what? At least those enterprise idiots will run JVM instances on their docker images, so if they need more than three servers it's not because they are incompetent (like every startup wasting their time on cloud orchestration stuff). At least when they pay the price in complexity for building something scalable it's because they actually need something scalable.
We're a small company and so far we've never found a role for Docker. We just deploy stuff to VMs and bare metal servers with Chef. Docker is occasionally useful for testing and builds but that's about it.
But... the thought of coordinating the way we do things with 100+ developers working under layers of middle management is terrifying. Stuff would be breaking left and right. It would be a disaster.
For that we'd want a true zero-interdependency micro service type way of doing things where everyone's part is a different product and is deployed as a completely separate monolith.
For that Docker with all its warts and inefficiencies is an acceptable, standard solution. As you say it's not ideal or elegant but it works and people know it.
Meanwhile, the booths were 50% "we can install Kubernetes for you" and 50% "we can do monitoring/logshipping for your Kubernetes", which is interesting given that the Kubernetes guys are working on solving the first issue and Prometheus/Grafana/Fluentd solve the second issue already.
Fluentd is a terrible log shipper: sub-second timestamping is not yet supported in the stable build, support is patchy in the plugin ecosystem in 0.14. There's also some humdingers buried in the source (Rational numbers for time arithmetic?) Abstractions leak all over the place. The plugin ecosystem is weak and the API shims in the minor version API break are poor and in my experience break semver.
Prometheus has the right idea, but I wouldn't want to be running and scaling my telemetry system if I'd also taken on the burden of running my own container scheduler. Whilst I've no doubt Prometheus can be made to scale, I'd rather somebody else made the federation decisions for me.
Oh well :\
One problem with the Austin convention center is that it's VERY spread out, so it's easy to miss an entire chunk of sessions because they're almost impossibly far if you don't know what you're looking for.
As this thread insinuates, Docker is a VC-driven fad that has been seized upon by posers as the next buzzword to plaster across their resume. I wish more engineering managers were willing to stand up to this nonsense.
The small number of enterprises that are doing containers are going to Kubernetes for technical credibility or Redhat OpenShift for enterprise credibility.
Instead of trying to be a platform company for the enterprise, Docker should have just licensed and supported the Docker engine to the mass market (their one moat) and absolutely cleaned up.
I give them a lot of credit for noticing that nobody else was capitalizing on the existing container tech. But it did exist already. They didn't invent something new. They just put a nice cli, daemon, and image repository around it. I think they know the "license the engine" bit is a non-starter, as the higher level container orchestration platforms are already abstracting away from it.[1]
[1]http://blog.kubernetes.io/2016/12/container-runtime-interfac...