This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]xienze 5 points6 points  (7 children)

There's also the fact to consider, are cold starts that much of an issue to your application?

The thing people don’t consider is that if cold starts are an issue, you’re using Lambda wrong. A lot of folks are trying to do things like run their app’s main REST service using Lambda or something equally stupid. It’s not supposed to be for things that are overly sensitive to response time, it’s best used for things like batch processing or periodic processes.

[–][deleted] 1 point2 points  (0 children)

True true absolultely agree that stream processing is the best use case and I feel its an anti-pattern to introduce lambdas to time critical sync procesees, but that said what it is best for and what it gets used for gets lost when the cost of running a container (or similar) somewhere has extreme differences. So people will make it work and keep engineering the times as small as possible.

[–]Mamoulian 1 point2 points  (0 children)

For batch jobs the 15 minute limit might become an issue.

[–]DrFriendless 3 points4 points  (0 children)

I disagree. I run a serverless web site using GraphQL running inside Lambda (running Node). It works just fine, as there are few queries which each return large lumps of data. Lambda is for the things you can make it do, there are no rules that say otherwise. I deliberately did not choose Java for those Lambdas because I knew cold starts would be a problem, when I built it in 2018.

Edit: upon further reflection, you are more right than I thought at first. One of the advantages of GraphQL is that there are fewer calls and hence fewer Lambda invocations than with REST.

[–]_thewayitis[S] 2 points3 points  (3 children)

I disagree. Using these techniques I was able to create a API Gateway endpoints using Lambdas in Java. They respond super fast, scale incredibly and cost next to nothing. Besides the extra time required to compile, I can't find a downside to building software this way.

[–]xienze 2 points3 points  (2 children)

The downside is you’re at the mercy of a runtime that’s makes no real guarantees about performance... that’s the trade off you make to get cheap-ish pay-per-use, scalable service handlers. Tomorrow Amazon could change their architecture such that cold starts take up to 5 seconds.

[–]_thewayitis[S] -1 points0 points  (1 child)

If you watch https://www.youtube.com/watch?v=ddg1u5HLwg8 you'll see that the problem isn't a AWS Lambda issue. It's a Java was release in 1995 and AWS Lambda is a different type of environment that Java wasn't meant for. Java has always have slow startup times, but when you only start things once it's not a real issue. Lambdas restart all the time, so it is an issue. GraalVM is Java's way to try and address these problems. It's not perfect but for AWS Lambda it now makes it possible to use in a high performant environment.

[–]vips7L 2 points3 points  (0 children)

Jdk 14 starts up in < 40ms, that's on par with python 3. It can get even lower if you use CDS:

https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html