News for hackers. Stuff that matters.
Re:Serverless Architectures by falcolas on Friday June 17, 2016 @09:33AM (#11922529)
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.

Re:Serverless Architectures by beat on Friday June 17, 2016 @01:15PM (#11923926)
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.