It's the Future

Funny you say that. I just had a conversation about a meeting I was involved in a few years back when our EE's didn't understand why we thought it was a spectacularly bad idea to design our own Pentium-class CPU boards vs. just buying them off the shelf.

Cost advantage? What's that? We just want a cool project!

> Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md

From the perspective of this longtime software developer, this isn't that great either. I'll try to give some specifics.

* The terms "container" and "containerization" seem to mean a lot to the author of the document, but they're never defined well and they're used an awful lot despite this. That kind of thing isn't half-bad marketspeak if the point is to get people thinking about this in the vague "It's the future!" manner that The Fine Article is satirizing (and/or accurately reporting as part of the social dynamics of the industry). The invocation of an unfamiliar term over and over can serve as a form of social proof and generates curiosity. But it might well be what's triggering suspicion on the part of some engineers.

* Positioning containers as an alternative to VMs is somewhat helpful in giving at least some idea of what kind of rough problem space we're working in -- someone familiar with a VM knows that they're often used to reproduce the specific runtime environment a given application needs. But by the end of the section I still have no real idea how "containers" are different other than that they're "lighter." Except for one clue: I know what FreeBSD jails are. So I might guess that something like them is involved -- but you're describing them as "primitives", so there's something else involved and I don't see an explanation of what it is. Is Docker a glorified chroot jail? If it's something more, what's the additional value?

* And... two sections down "escape dependency hell" -- that might be the additional value prop! But again, this section is really confusing. Dependency management means package management, right? But it's being done with Yet Another New Undefined Entity called "Layers" without replacing any other package manager so... we have two package managers? Or Layers aren't package management? What the hell are they? I could guess they're something like an image but I have no idea.

* "Plays well with others" Gives strong hints this is mostly a Unix thing (which, if this is some kind of enhanced chroot jail makes sense). Somewhat in conflict with the hints of platform agnosticism earlier in the document. Is there a story here for Windows, either as a host or for windows apps?

* "Real World Examples" These tell me how to "Dockerize" different server apps... but there's no context about why I might want to do this. What problem am I trying to solve?

And that's the thing -- at the end of this, I don't know what problem I might be trying to solve with Docker. I might guess Docker helps me deploy an application along with a specific normalized runtime environment, but that's from a lot of guessing and reading between the lines rather than from an upfront communication from the text itself.

If my description is accurate, a clearer version of it should be your first sentence. Followed by a second paragraph telling me enough about some specific frictions you've done away with compared to other solutions that I'm wanting to learn more. Then tell me some specific stories about situations where someone might have a problem that Docker is a good fit for, and explain the rough usage that be applied to address it.

From my experience, it's not either-or. First you need "bottom-up" adoption by actual practitioners (in the case of Docker, developers and sysadmins). Then you also need to understand the constraints and requirements of people who are in a position to say "no". Those include managers, but also procurement, architects, network engineers, security teams, etc. Those people aren't the ones championing your product (most of the time they don't have very strong opinions either way), but they have a job to do, and if a new dev tool affects their ability to do their job, they're going to say "no".

It's very common for developers or sysadmin to contact us and ask for a powerpoint deck, so that they can give a convincing presentation to their management about the virtues of using Docker in their new project. We even have specialized teams that go in and do everything they can to help Docker-based projects succeed.

But as you point out, it all starts with someone inside the organization who really, really wants to use your product. Otherwise no amount of messaging is going to save you.

Or use cloud foundry (http://cloudfoundry.org/index.html) if you have a burning desire to stand up your own paas vs. just using heroku.

What's funny is that CircleCI is one of a million CI deployment services out there too.