On the usefulness of containers like Docker

The article Works on most machines by Mark Seemann (Ploeh Blog) argues provocatively that containers are a fallback for poorly written software.

“When you have general-purpose software, though, do you really need containers?”

Well, yes. The point isn’t that you need a container to paper over software that isn’t sufficiently generic: it’s to avoid fixing incompatibilities that have nothing to do with your target deployment systems.

I think the author is thinking too much of highly general-purpose software whereas the majority of software doesn’t need to run everywhere and anywhere.

If it’s built for the cloud, it’s going to run in a container anyway. If it’s built for a specific device, it’s going to run on that device.

In that case, why not just run that software at the developer side in the same environment? That way, you can avoid wasting a ton of time fixing problems that are related to how it runs in development rather than production.

“Ultimately, you may need to query the environment about various things, but in functional programming, querying the environment is impure, so you push it to the boundary of the system. Functional programming encourages you to explicitly consider and separate impure actions from pure functions. This implies that the environment-specific code is small, cohesive, and easy to review.”

It implies it, but it in no way guarantees it. The author is also forgetting about the quality of the developer that is likely to be building the solution.

In this post, he assumes that the developer uses enough tests to thoroughly test the system—even to the point where he is able to determine where a solution isn’t sufficiently generalized yet. He assumes that the developer uses methodology like functional programming to separate pure from impure code, and that the developer is good enough to do all of this in a way that is both efficient and leads to a finished product.

This is not at all a guarantee—or even a likelihood—in the real world.

In the real world, developers are not reaching for the stars—even if they had the capabilities, which many do not, they’re often not given the time to do things correctly—they are just trying to get it done.

If they can “cheat” by restricting the world of possible environments—rather than accommodating their software to environments it will never encounter in production—then why not?

It’s actually an engineering problem. If you’re going to make something that has to work well underwater, the only reason it needs to work out of water is because it makes it easier to work on, not because you think it’s worth the time making it function properly when in air. If you can make it just as easy to work on underwater than you it is in air, then you would just do that instead. Wouldn’t you? Why waste your time and your company’s when there’s a lot of other, more important work to do?