Hacker News Reader

Comment by jaredklewis | Hacker News Reader

Sometimes the proof is in the pudding.

I’ve had similarly adverse reactions to the seemingly “unnecessary” complexity of many things: docker, webpack, autotools, react, AWS, just to name a few.

But I’ve found that, upon closer inspection, the software is usually complicated because the problem domain is complicated. Further, as an inviolable rule, the most popular tools for any problem are the ones that don’t make you rewrite all your code; popular tools build on top of the mess we already have. This can give the illusion that the tool is somehow responsible for all the preexisting complexity. Tools which attempt a “clean slate” approach are mostly doomed for obscurity.

In the case of docker-compose, I can say after years of resistance, I tried docker compose and was an immediate convert. Setting up, documenting, and sharing development environments has never been simpler.

View on HN

I would add a caveat: Docker compose is nice for setting up development environments as long as everyone's developing on the same platform.

I work in a shop where various developers work on Linux, OS X and Windows (useful for dogfooding - we support deploying to multiple platforms), and, there, Docker Compose has ironically turned out to be our chief source of cross-platform headaches, due to annoying differences in how it works on each host platform. Particularly with the networking subsystem.

> Docker Compose has ironically turned out to be our chief source of cross-platform headaches

Which is the whole point of it. If it's not, it's just a bad abstraction. Docker-compose itself becomes the only variable

Perhaps I should rephrase:

Since moving to Docker, we now have more cross-platform problems than we used to.

We continue to use it anyway, because there are some other benefits that we feel outweigh shortcomings like these. But still, it's annoying.

To be fair it's an issue with docker, not compose (volumes, networks differ in implementation between platforms)

Everywhere I've ever worked that had docker/vagrant, the devops guy has promised me easy, one command environments, and not once has it worked.

I've seen the product they are selling, I've watched a docker command build me a multi-part infrastructure, automatically source databases and assets from afar, and do it all quickly. But then it failed the second time I tried it. I've not found it to be a reliable tool at all.

Even in a shop with just Linux and mac, I think docker (especially deployed via fargate) causes way more problems than it solve. We have a single instance of a single app that used to run just fine in a Ubuntu vm. Now it runs in fargate. We waste huge time futzing with the image size due to fargate insane 8gb limit. We wast huge time working around not being able to get a shell when something goes wrong.

Local development also sucks. The docker engine is essentially unusable on my colleagues Mac, consuming 100%+ of all available cpu while sitting idle. On my Linux box, either docker breaks my networking, or IT firewall rules break dockers networking. It’s even worse with wfh, because our vpn is incomparable with docker. Local dev just happens in an anaconda env instead. So what’s the point?

VMs have none of these problems. Docker is the leakiest abstraction I’ve yet to come across.

I'm not incredibly knowledgeable about AWS and Docker, but I have a couple questions for you:

- How would EC2s compare to Fargate ? I encountered situations where, running the numbers, I much preferred having my own set-up with images ready to deploy + adapting my EC2 instances to the task, instead of dealing with Fargate's convoluted restrictions and definitions

- Has your colleague tried to increase the disk size given to Docker? I have seen on a few macbooks that this made a world of difference for CPU usage, and I thought I'd pass on the information if it hasn't already be tried yet

Reply on news.ycombinator.com