Hacker News Reader

Comment by hueving | Hacker News Reader

>you have to Implement sticky sessions.

There is more to the world than serving HTTP requests.

To expand on your point, there is also more to cache than user-specific data. Exchange rates, tax rates, product catalogs, and more can be usefully cached without requiring sticky sessions.

who keeps that data locally on the server?

If you're querying the IRS for tax rates every time you run a calculation, you're doing it wrong.

If you aren’t querying exchange rates often - you’re also doing it wrong....

Depends on what you're using the exchange rates for. The rates used by Visa only change once per day, as an example.

And you still wouldn’t store that locally. You may cache it locally - something you could also practically do with lambda.

Well yes, the parent we're replying to was talking about caching.

Anyone implementing business-critical applications which have to continue to function if external services go down.

Ever wondered how cash registers work? Exactly like that. The world may burn down around you, but as long as your cash register PC is running, it must continue to at least offer basic functionality.

You mean like all of the cash registers at companies like Target that were breached because they were distributed?

https://www.post-gazette.com/business/2013/12/19/Target-ackn...

The vast majority of point of sale systems are networked, and this is nothing new. There's literally millions of PoS systems out there running off of AS/400 backends, even today.

Things like exchange rates, catalogues, tax rates are not generally 'session oriented' anyhow. They could be cached by some other means hopefully at least somewhat transparent to the business logic anyhow, so to the OP's point, I don't think this is a limitation.

I'm in agreement that the fundamental limitations prescribed in the article are academic for the most part. 'custom GPU's ' are not really what we're after with Lambda's etc, at least not yet - and I'll bet when we get to that point it may be possible to access specialized hardware in Lambdas as well.

In addition, things like '15 minute timeouts' are kind of arbitrary product design issues: we generally don't need 'long-timed Lamdas' because that's not what they are for. Something that needs 15 mins of crunching is better suited to another piece of the infrastructure anyhow.

Serverless computing, done in a manner that can doesn't throw up a bunch of hurdles definitely has a lot of advantages.

The more obvious downside to me is the degree to which they are all fairly custom implementations, and that Lamdas aren't so easily ported between providers.

Sure, you have communications over queues, event messages etc. both supported by lambda. You also have higher volume messages from something like IOT devices where you would use something like Kinesis.

Are FaaS’s fundamentally aimed at those use cases?

Yes. Those are all processes that are “embarrassingly parallel” workloads. You can just point lambda to a queue for instance and it will automatically scale based on workload. When nothing is in the queue, you’re not paying for resources just to poll an empty queue.

Reply on news.ycombinator.com