Hacker News Reader

Comment by dchuk | Hacker News Reader

Because they're so damn complicated.

The guys at my work made the switch to containers months ago and we've yet to realize any gains from them, whether that be productivity, efficiency, cost savings, scaling...the list goes on.

Development is more complicated and slower, everyone is on macs so docker runs like shit (I know I know there are syncing plugins but that's a workaround hack).

Even though I'm no longer an engineer and instead am in product, I still have strong opinions about a lot of things technical so I have to bite my tongue sometimes and trust team members.

It's just hard to watch people lose sight of the Why's for doing something and instead gravitate to that cool new shiny thing, even though it adds more layers of abstraction and complexity than most teams need.

View on HN

> The guys at my work made the switch to containers months ago and we've yet to realize any gains from them,

> Development is more complicated and slower, everyone is on macs so docker runs like shit

That's probably related to the complexities of your specific architecture, applications, and infrastructure.

We are mostly a python shop and containers were a game changer (we've been using Docker since it was a beta product). The consistency between development/deployment and the ease of deployments made it possible to rapidly iterate in a way that wasn't possible in the past (deployments used to be a whole day affair and now we deploy multiple times a day).

Likewise with OSX development - the isolation of the container makes it far easier to manage dependencies and have a consistent experience with QA and production. I've also used it for horizontally scaling geospatial analysis - commands like "docker service scale gis=500" make it trivial to run complex analysis across multiple hosts compared to the alternatives.

Docker + Python API's + HTML/JS front ends has been nothing but smooth sailing for the past few years.

To play devil’s advocate, if you already have a build process with repeatability and a close corellation to production, containers may seem like robbing Peter to pay Paul.

For one thing people almost always end up reworking their layers to go from least to most frequent changes for speed, but that often confuses the issue of logical units of work within the setup code.

And if you’re using npm or gem in a container, on Mac, You are going to experience some strong, negative feelings.

I don't disagree. As I said it's "probably related to the complexities of your specific architecture, applications, and infrastructure."

Use what works for your environment and team.

I use vagrant with the same os as the server for whatever project I'm working on. What's the advantage of docker over this?

The first, obvious thing you would notice is performance. A docker container typically starts up in a fraction of a second (whatever process is running inside it might take a few seconds more) while a vagrant VM has to go through a whole boot up process. Docker has a slight overhead on disk I/O, but it's still far better than a typical vagrant setup. A docker container has very little memory overhead beyond what the process is using vs vagrant requiring you to allocate a fixed amount per VM. It's completely reasonable to run dozens of containers simultaneously on a laptop all completely isolated. Doing the same with vagrant would require an enormous amount of memory.

The bigger advantage is the switch in mindset that is much harder to explain or quantify.

> What's the advantage of docker over this?

To be honest, I don't know enough about vagrant to fully answer this.

I'm curious if there are any advantages with vagrant over Docker?

Scale is a missing component for most such fads. Overhead that can easily pay off when you do 100,000x, is a much larger burden at 100x.

Works great at Google / Netflix / Facebook is basically meaningless for 99% of everyone working in the field.

Exactly this.

I won't advocate for setting up all development to happen inside containers, but delivering software with containers is an order of magnitude simpler than delivering to a running os.

You need packaging, update scripts, init scripts and strict policies for upgrades and do coordinated library updates (on the shared environment), or nearly roll your own os where you bundle your dependency with the app. That is incredibly time consuming.

With containers you don't need init scripts, the team can update any dependency when they want/need without breaking someone elses environment. And with containers every team deliver the same 'thing', a runnable image. Not a blob of php, some ruby and java ear and wars that have to run on a shared platform.

Its easier for the software developer to maintain. Its harder for the software user to maintain though.

I'll never understand the love for containers. Seems like a ton of work for little gain.

Having done some development in containers on Mac, I totally agree that it's not worth it (at least for the front-end builds I was trying).

I do think that they have a valuable role in deployment. They provide a simple contract that expresses a particular service's needs and side-effects cleanly.

I also think they are valuable when your stack has dependencies that you are not actively working on. Having a docker-compose to orchestrate those things has been a pretty solid productivity win at the one company I've been at that used that system.

100% agree that developing in containers just isn't worth it right now, at least for things with a somewhat complex build toolchain.

> Having done some development on Mac, I totally agree that it's not worth it.

FTFY

> people lose sight of the Why's for doing something and instead gravitate to that cool new shiny thing

This, to me, is a critical problem with our industry. I see so many times the same wheels being reinvented simply because the developers didn't take the time to learn from history.

See "Object Oriented Programming" - approx 1994.

Reply on news.ycombinator.com