undefined | Better HN

0 pointsfalcolas10y ago0 comments

They are not always terminated, in an effort to avoid cold boot startup times. In fact, they run much like any other service framework, where your code is behind a function lookup, and called when an appropriate request is received.

AWS Lambda in particular will spin up a new container running their framework, which will then stay alive for a period of time before being terminated.

With socket activation (using xinitd or systemd) and a minimal framework, you could implement much the same on your own VMs.

0 comments

3 comments · 1 top-level

osipov10y ago· 2 in thread

>They are not always terminated, in an effort to avoid cold boot startup times.

That's true. I should have pointed out that from the developer's point of view it appears as if the execution is terminated, in the sense that no state is carried across code executions. However, the issue of whether the code is cold booted or not is an implementation detail of a specific serverless platform.

Atlassian did a nice blog post[1] on running Docker containers using socket activation. In principle that makes for a serverless platform but for a one that's difficult to manage. [1] https://developer.atlassian.com/blog/2015/03/docker-systemd-...

falcolasOP10y ago

Any code written in a common web framework (such as Django, Rails, or Play) could easily be written with the same constraints - no state left over from request to request. That we typically choose to retain state between requests as an optimization speaks of one of the weaknesses in serverless architecture.

If you can't maintain state inside the application, you need to maintain it elsewhere (DB, Redis, memcache), and that elsewhere has a cost associated with accessing it.

beat10y ago

That's a part of Twelve Factor apps as well. No state in the app! And while there is a cost to keeping state in an external data store like Redis, there are costs to keeping state in the app as well. First, there is the question of complexity and testability. Your app becomes harder to reason about, harder to test, and much more likely to be dependent on complex integration to get to a testable state. Second, there's the need for external support for internal state in any horizontally scaled app. This can be very expensive.

Consider session state in a web app. If you keep state in memory and scale horizontally, you need session affinity, so stateless inbound http connections hit the same server instance. That means a session-aware router, delicate and extremely expensive F5s and other "smart" routers. But if the app is stateless and session state is in external storage, then all you need for load balancing is a simple round robin. A cheap router, that's more reliable and requires less administration, for a fraction of the cost.

There are other ways stateful apps are expensive, but that's a big one. I'd rather pay $5k than $100k for a router.

j / k navigate · click thread line to collapse