Item — HN Reader

At the risk of displeasing the Docker crowd, I would say you can get pretty far without them.

In general, I see a lot of people learning and using BuzzWord solutions for problems that they don't have.

In most cases, you'll have some problem and look for a solution to it. If your problem is spending a lot of time messing around with dependencies and deployments and "but it works on my machine" type issues, then Docker may well be the solution.

If you learn a solution and then see what problems it can solve (Hey, everyone is talking about Docker. Let me learn it too), you'll end up frustrated and confused.

Of course, it's a balance -- often you can learn about problems that you didn't even know you had by learning about new technology. But so far I see more people erring towards "Let's fix these problems I don't have" than "I'll just keep doing things this slow old way because I don't want to keep up with tech movements"

2 comments

Having worked for for about 18-20 different clients I can count on my left hand the number of places that had turn-key, repeatable dev environments. Repeatable prod environments are usually better but not always.

Quite honestly to most lazy developers the idea of repeatable and turn-key environments is anathema to them. "It's time consuming". "It's boring." "It's Somebody Else's Job." It is now my number one way to determine actual seniority and skill level in a developer during interviews.

Docker is not the panacea, but it's a game changer for many people as it lowers the barrier to entry for these things. We should embrace containers for what they are -- a very useful tool.

> turn-key, repeatable dev environments

> We should embrace containers for what they are

Um.. relatively unrelated to the problem you described?

Containers are about isolating one or more processes, memory, network, disk etc from the rest of the host system. This can be used to achieve security benefits, and/or to resolve dependency differences.

The problem of repeatable dev environments is solved almost always by a single concept: script it, either using shell scripts, or a configuration tool like Chef, Puppet, etc.

In Vagrant, this means one or more provisioning scripts executed in the guest environment (usually a VM, might be LXC or Docker). In Packer, this peans one or more provisioning scripts executed in the guest environment (usually a VM, might be LXC or Docker). In Docker, surprise fucking surprise, it's a script executed in the guest environment.

No, they are not unrelated. Isolation yes, and through that, you get repeatability. We can all agree that declaratively describing your environment (Salt, Chef) is preferable to the rather simplistic Dockerfiles currently in use, but both aim to accomplish the same time. I remember the pre-container days of re-running Salt/Puppet scripts over and over again in a VM until it works. Nothing wrong with that - they're great tools. I also remember the pre-Salt/Puppet days of using shell scripts. None of the above are great: conf. management + docker is a better solution long-term for building a container image.

My point is that Docker itself brings nothing to that 'repeatability' table. You have that with shell scripts, salt/chef/puppet/what have you, all of which can be run on any environment that meets the baseline requirements for your project.

It's fairly common to use Docker to run other services (database, cache, etc.) needed when developing a web app.

I assume you're talking about running multiple images concurrently, each one focussed on it's own specific role.

Sure, you can do that too with Vagrant. Vagrant isn't limited to running a single machine for a given Vagrantfile.

On what technology? Working with .net + nuget the environment is generally pretty repeatable, the only big outside dependencies to worry about are the .net framework itself and sql server. Others like java and rust are pretty similar AFAICT.

> I see a lot of people learning and using BuzzWord solutions for problems that they don't have.

THIS more than anything is the biggest issue I have when dealing with clients.

"Hey we need your expertise, this is our problem and we want to use <Docker/Kubernetes/AWS/MongoDB/<$NAME YOU COOL KID FLAVOUR OF THE MONTH>".

Thankfully, most people will listen to reason when you point out how $X won't actually solve their problem but $Y (which they've likely never heard of or dismissed because it's not being hyped by VC funded startups trying to defend their own poor choices) could.