Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

> Unless you're performing a larger job or something you probably need to read/write data from somewhere and connecting to a normal database is too slow for most use-cases.

This is false. I've seen entire Lambda APIs backed by MySQL on large, consumer-facing apps and websites. As another poster pointed out, the cold-start-in-a-VPC is a major PITA, but it can (mostly) be worked around.

View on HN

And there is always DynamoDB where you aren’t in a VPC and Serverless Aurora where you don’t have to worry about the typical database connections and you can use the http based Data APIs.

Dynamo is really the hardest lock-in in the ecosystem for me. Serverless Aurora is still easy to kill with too much concurrency/bad connection management compared to Dynamo

That’s theoretically where the Data API comes in.

How is the Aurora Serverless Data API now? On preview release it was a bit sketchy: horrible latencies (pretty much ruining any benefit you could get from avoiding the in-VPC cold start) and a dangerous sql-query-as-a-string API (no prepared statements or placeholders for query params that would get automatically escaped IIRC).

Unfortunately, we require the ability to load/unload directly from S3 and Aurora serverless doesn’t support that. We haven’t been able to do anymore than a POC.

VPC cold start times are the bane of my existence. I do hope they deliver the super-fast cold starts they promised this year

Can you explain this more? Is this if your lambdas haven’t been hit in a while, in the background aws will scale things down?

Or is it when deploying new code?

When lambdas haven't been hit for 15mins the first hit after has a noticeably longer start time. It's due to deprovisioning/reprovisioning underlying resources like network interfaces. Some people do crazy stuff like a scheduled task to hit their own service to combat this so AWS promised to solve it.

Even if you invoke your lambda function to warm it up in anticipation of traffic, you'll still hit cold starts if the lambda needs to scale out; the new machines are exposed to inputs "cold." Those crazy patterns trying to warm the lambda up are really crazy if you think about it because no one is using them is really aware of the underlying process(es) involved.

"Why are you throwing rocks at that machine?"

"It makes it respond more quickly to actual client requests. Sometimes."

"Sometimes?"

"Well, most the time."

"Why's that? What's causing the initial latency?"

"Cold starts."

"Yeah, but what's that mean?"

"The machine is booting or caching runtime data or, you know, warming up and serverless. Anyway, don't think about it too much, just trust me on this rock thing. Speaking of which, I got to get back to bastardizing our core logic. Eddie had great results with his new exponential backup rock toss routine and I'm thinking of combining that with a graphql random parameter generator library that Ted said just went alpha this afternoon."

yo can I get a link to that gql random parameter generator library?

Exactly - this blog post I've always thought was a great overview: https://hackernoon.com/im-afraid-you-re-thinking-about-aws-l...

If initial startup time - and long periods of non usage - is an issue, wouldn't a permanently running VPC for the initial load be a better solution?

In addition to what the sibling reply said. There is also the issue of your choice of runtimes. Java has the slowest startup time and Go the fastest. C# is faster than Java but still slower than Python and Node.

Clever uses of dependency injection without reflection (think dagger not spring) and reducing code size as much as possible can give you fairly fast cold start times with a Java execution environment. Bloated classpaths and reflection filled code will destroy your initialization time.

And by "…Go the fastest." I assume you mean compiled languages.

Until last year at ReInvent, you could only use one of five (?) supported languages. Go was the only compiled language available.

Reply on news.ycombinator.com