Hacker News Reader

Comment by nickjj | Hacker News Reader

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 downtime, assuming you're not load balanced.

I opened an issue for this almost a year ago but not too much has come from it other than identifying there was maybe a regression in recent'ish versions: https://github.com/moby/moby/issues/38077

We're talking multiple seconds in Docker vs ~150ms as a regular process to start up a typical web app process like gunicorn in a decently sized Flask app (many thousands of lines of code, lots of dependencies -- a real world app).

View on HN

I take it you've never worked in an enterprise Java shop with a few million line legacy code base deployed to whatever the hell webserver I can't remember the name of right now.

Seconds is great in comparison. Minutes, not so much.

JBoss, Websphere? I know that pain, hadn't even occurred to me that anyone would think containers had a slow startup time. Especially as they've often replaced VMs for me.

WebLogic.

this name brings back lots of painful memory back in the day.

The long startup time is somehow what keeps me from really liking Docker. In the end (if I understood correctly), it is supposed to be the go-to tool for serverless architecture. If my serverless function needs more then a second to startup, it's not usable for me.

Even the hello-world container, which is only a few kB in size needs roughly a second to startup.

> In the end (if I understood correctly), it is supposed to be the go-to tool for serverless architecture.

You misunderstood. No one calls Docker a “serverless” architecture.

And i didn't either, I called it a tool for serverless architecture. In fact some tools for serverless architecture like AWS Fargate require you to use Docker.

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.

How do you come to this conclusion from this pricing page? [0]

I might be missing something but that seems like serverless pricing. You might be thinking of the pricing scheme when Fargate first launched? Or maybe you’re thinking of ECS, which does in fact charge as you described.

[0] https://aws.amazon.com/fargate/pricing/

Everything I am reading there screams container service and not serverless. Some Quotes:

> You pay for the amount of vCPU and memory resources consumed by your containerized applications.

How does vCPU fit into serverless architecture?

> Pricing is based on requested vCPU and memory resources for the Task.

Tasks being a collection of Containers. This is simply a container service like ECS or EKS.

> Pricing is calculated based on the vCPU and memory resources used from the time you start to download your container image (docker pull) until the Amazon ECS Task terminates.

This means you pay for the resources that were started for your containers until the container ends. Including all idle time and any overprovisioning you did because you have to tell it which instance type you want. Compare that to the pricing of Lambda where you only pay for the time your functions need to execute when they get called based on external events.

To bring this back to the beginning of the discussion: Complaining about docker because it is not a good tool for serverless architectures is not smart because it is not used in serverless architecture offerings. Fargate uses containers but it is not a serverless service. Fargate is a container service that tries to simplify setup of compute clusters in comparison to ECS, EKS and EC2.

From https://www.learnaws.org/2019/09/14/deep-dive-aws-fargate/

> Fargate and Lambda are both serverless technologies from AWS.

I'm working on a web service that takes 4-5 minutes to startup because of all the shit it has to warm-up. I'd be happy if it takes even a minute IF I could port it to a newer tech stack and can containerize it.

- start the container with docker run and run sleep 999

- then start your application with docker exec

you will have instant execution.

Only restart your container if the environment changes (new build etc.)

For development, mount your source code in readonly.

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.

> 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.

I've been part of Ruby teams and Rails apps can start almost as slow as Java apps. Big .NET projects, too.

Plus there's probably 10x more Java developers than Ruby developers out there. And Elixir/Phoenix devs are probably 0.001% of Java devs :-)

It depends on how big the Rails app is.

One app I work with has 40 top level gems and about 17,000 lines of Ruby code (which goes a longs ways in Rails). It's not "big big" but it's not tiny. It takes under 10s to boot up. I'm sure if you have a Shopify-tier app it takes much longer, but a majority of apps aren't at that scale.

I was just throwing out examples and I'm just trying to say not everyone is dealing with cases where Docker's added 2-5+ seconds isn't a big deal. For a Flask app those few seconds make it ~20-50x longer to start up due to Docker and for a majority of other frameworks / average app sizes, it's a non-ignorable amount.

Firecrackers are fixing that.

https://firecracker-microvm.github.io

Reply on news.ycombinator.com