QCon New York June 15-19, 2020 | | Fearless AWS Lambdas

What You’ll Learn

Gain practical knowledge about experiences running JVM-based Applications on AWS Lambda.
Learn about some of the performance numbers and metrics captured from running on a serverless platform.
Understand best practices and hear recommendations on how to effectively leverage cloud serverless function.

Abstract

The modern Java Virtual Machine (JVM) is the culmination of millions of hours of expert engineering, and is the foundation on which enormous portions of the digital landscape are built. However, as a runtime for AWS Lambda functions, the JVM is often derided as being a poor fit for an ephemeral world. The truth of the matter is that the JVM is an excellent choice of runtime for a wide range of AWS Lambda use cases, and developers need not even constrain themselves to just the Java language to use it.

In this talk, John Chapin gives an overview of the JVM runtime for AWS Lambda, as well as a comprehensive look at JVM-based Lambda performance across a range of use cases. He outlines a set of criteria to help architects and engineers decide whether or not to choose the JVM over the other runtime options. He also gives strategies, tips, and examples for developing efficient, performant AWS Lambda functions in a variety of JVM languages, including Java, Clojure, and Scala.

Question:

QCon: What's the big thing you have to be aware of when running Java on AWS Lambda, and how do you address that in your talk?

Answer:

John: You have to be very cognizant of the cold-start initialization behavior of your application (and the underlying runtime) versus the warm-start behavior of your application (and that runtime).

Both the beauty (and the challenge) of a platform like Lambda is you give up control. As we moved along this path, where we went from running on premise (where we did everything from bare metal on up) to a managed functions as a service platform, we're losing dials and losing opportunities to control the behavior of the runtime. So with Lambda, we only have a couple of knobs left to turn to adjust the behavior of the runtime. The thing that affects Java the most is of course artifact size.

As Java developers, we are used to just plugging the library that we need into a pom file, and it downloads. So I go into some detail about how to be circumspect and conscious of your application dependencies.

Question:

QCon: What about issues around JVM warming. With AWS Lambda having an ephemeral JVM, how do you address that cold-start problem?

Answer:

John: The good news is that the platform itself only undergoes cold starts when it needs to create a new container. For example, like the first time you run your Lambda, reconfigure your lambda, or maybe when you scale out, you will see it. What we see (and we have a lot of data on this) is that it tends to be four to six hours before you have to have a cold start.

[If you're running a fairly regularly invoked lambda function (and not having a ton of failing behavior), you may only actually pay that cold start penalty a few times a day. If you're doing something in the execution of your Lambda function that's even marginally complex, this is usually enough to see the performance of the JVM drastically exceed that of a Node or Python. By the way, I'll caveat that statement by saying Python not using some of it's C/native library stuff. So so do the math. We'll talk about how to do that and how to go into some detail about how the benchmark standards because the platform is very very hard.

Question:

QCon: How much configuration do you have over the JVM when you're running on Lambda?

Answer:

John: You have you have no control over any of the runtime parameters of the JVM, other than you can set the memory allocated for a Lambda and the max heap for the JVM is 85 percent of that.

Speaker: John Chapin

Cloud Technology Consultant with an expertise in Serverless Computing

John Chapin is a co-founder of Symphonia, an expert Serverless and Cloud Technology Consultancy based in NYC. He has over 15 years of experience as a technical executive and senior engineer. John was previously VP Engineering, Core Services & Data Science at Intent Media, where he helped teams transform how they delivered business value through Serverless technology and agile practices. Outside of Symphonia, he can be found running along the west side of Manhattan, surfing at Rockaway Beach, or planning his next trip abroad.