Live data from Hacker News

Dissatisfied with Docker

robert.ocallahan.org

171–180 of 229 posts

Re: Dissatisfied with Docker

#171
post #78
post #71

Earlier quoted context omitted.

I just recently switched to using vscode with the remote ssh plugin and setup an ubuntu vm on my windows machine and performance is like 100x better. Docker for mac is basically dead to me now, going to finish migrating my projects over to the VM and uninstall it from my laptop.

Have you tried running the Vscode + Linux Subsystem + Docker on Windows stack? It's been pretty good so far (a good writeup on this is at https://nickjanetakis.com/blog/setting-up-docker-for-windows... )

Thanks for sharing that link, author here.

Yeah I don't know why but on Windows the volume performance generally seems to be a lot better than Mac.

I have nothing but good things to say even on 5 year old hardware. Massive web apps (including using webpack) are very very speedy with volumes with a number of different stacks (flask, rails, phoenix, webpack, node).

I still use that set up years later and it's really solid.

Re: Dissatisfied with Docker

#172

Earlier quoted context omitted.

There's also software that was created to solve a specific problem that got misappropriated to do something else There used to be an ISP called pilot.net. It was a crappy ISP but to solve its ISP billing problem it wrote a billing system for telcos. There was a company that tried competing with AWS selling hosting based on hyperthreads of CPUs. It wrote its own provisioning system because it did not want to pay for V…

> There's also software that was created to solve a specific problem that got misappropriated to do something else Docker is a classic case. Docker must be the craziest, most over-engineered solution for packaging developer artifacts in the Universe.

In the same way that Dropbox is the most over-engineered solution for file sharing, when all you need is an SVN-backed directory with curltmpfs. ;)

Re: Dissatisfied with Docker

#173

A few things that I would add to that list: o No primitives to deal with secrets. o Terrible disk handling (aufs was just horrid, overlay2 I think misses the point. device mapper is just, silly) o poor speed when downloading and uncompressing images. Of all of them, the most serious is the lack of secrets handling. Basically you have to use environment variables. Yes, you can use docker compose and stuff appears, but…

The most basic problem with Docker is the use of a daemon that is not init. Access control is at best problematic. Upgrading the daemon without losing state is tricky. Requiring daemon access to build images is insane. Building this functionality into something like systemd would be more robust but it's way harder to sell as a product.

Okay Lennart, if you say so.

Re: Dissatisfied with Docker

#174

Earlier quoted context omitted.

The most basic problem with Docker is the use of a daemon that is not init. Access control is at best problematic. Upgrading the daemon without losing state is tricky. Requiring daemon access to build images is insane. Building this functionality into something like systemd would be more robust but it's way harder to sell as a product.

Yeah Docker should get with the times and be assimilated into systemd like everything else

You could argue about many things bundled with systemd, but since containers are just souped-up processes, this is actually an use case that make sense for an init system.

Re: Dissatisfied with Docker

#175

Earlier quoted context omitted.

I know that AWS Fargate has the tagline of "Run containers without managing servers or clusters", but that is not what "serverless architecture" means. Fargate is a container service. Serverless would be, for example, AWS Lambda, Azure Functions or Google Cloud Functions.

Fargate is serverless because the compute is abstracted away completely. A lambda runtime is just a specialized container and they've added similar customizability to it lately with Layers/Runtime configuration.

I know that the definitions of these kinds of buzzwords can be fuzzy sometimes, but I have never heard a definition of serverless that would include Fargate.

Here is what Cloudflare uses to describe serverless:

> Serverless computing is a method of providing backend services on an as-used basis. Servers are still used, but a company that gets backend services from a serverless vendor is charged based on usage, not a fixed amount of bandwidth or number of servers.

With Fargate you still get charged for your running instances your containers are running on. Even if the containers themselves are idle. This is a container service and not a serverless architecture.

Re: Dissatisfied with Docker

#176
post #153
post #37

I've been using Docker since 2015ish and the container start up / stop speed is really the only thing that bugs me. Everything else is fine for day to day usage IMO (on Windows and Linux at least) and very much worth the trade offs, but having to wait multiple seconds for your app to start is tedious since it plays such a heavy role in both development and even in production. Each second your app is not running is do…

Few seconds are my dream coming true. Try working on an application where every deploy is a coffee break... :(

Firecrackers are fixing that.

https://firecracker-microvm.github.io

Re: Dissatisfied with Docker

#177
post #153

Earlier quoted context omitted.

Few seconds are my dream coming true. Try working on an application where every deploy is a coffee break... :(

Starting the process probably isn't what's taking so long though.

You'd be surprised. Big Java enterprise apps deployed to Tomcat or God-forbid! IBM/Oracle app servers can take 2-3-5 minutes just to be fully operational. I've had deployment health checkers timeout after 2 minutes because the servers just wouldn't be up. It seems insane, but that's how life looks for thousands of developers.

Re: Dissatisfied with Docker

#178
post #156
post #42

There are two kinds of software: software no one uses, and software people complain about.

Also feature complete software that is regularly used by lots of people, but nobody complains about, because devs don't mess with it anymore. Think ls, grep, yes, ...

Devs can't mess with it anymore, you mean? There's a myriad alternatives to ls, grep, etc. Dunno about alternatives to yes, maybe there's a si/oui/da out there? :)

Sometimes the alternatives are considered superior to the originals (ripgrep) but the originals are just fossilized in place. In 2019 I don't even think we'd be able to have less as the pager instead of more, because we're so conservative about universals defaults, it's sad.

Re: Dissatisfied with Docker

#179
post #42

There are two kinds of software: software no one uses, and software people complain about.

There's also software that was created to solve a specific problem that got misappropriated to do something else There used to be an ISP called pilot.net. It was a crappy ISP but to solve its ISP billing problem it wrote a billing system for telcos. There was a company that tried competing with AWS selling hosting based on hyperthreads of CPUs. It wrote its own provisioning system because it did not want to pay for V…

What's the link between pilot.net and dotCloud? Did dotCloud use the billing system from pilot.net?

Re: Dissatisfied with Docker

#180
post #177

Earlier quoted context omitted.

Starting the process probably isn't what's taking so long though.

You'd be surprised. Big Java enterprise apps deployed to Tomcat or God-forbid! IBM/Oracle app servers can take 2-3-5 minutes just to be fully operational. I've had deployment health checkers timeout after 2 minutes because the servers just wouldn't be up. It seems insane, but that's how life looks for thousands of developers.

> It seems insane, but that's how life looks for thousands of developers.

True, but there's tens of thousands of developers not using big Java enterprise apps where having Docker add 4-5-6+ seconds of startup time has a huge negative impact.

gunicorn (Python) apps tend to start in hundreds of milliseconds (even pretty big ones).

puma (Ruby) apps tend to start in seconds or tens of seconds (it can get higher for massive apps).

cowboy (Elixir) apps tend to start in low seconds (this includes booting up the BEAM VM).

Just the above 3 examples cover the Flask, Django, Rails and Phoenix ecosystem. That's a lot of developers.

Post reply on HN