Java’s Place in AWS Lambda: Why It Fell Out of Favor and How to Bring It Back

AWS Lambda has changed the way we build and run applications by offering a serverless computing environment. This means developers can focus on writing code without worrying about managing servers. When AWS Lambda first came out, Java was a popular choice for many developers. However, over time, Java has fallen out of favor for use in Lambda functions.

Let’s look at the challenges Java faced and explore the new tools and methods that can help bring Java back as a strong option for serverless computing.

Why Java Fell Out of Favor for AWS Lambda

1. Cold Start Latency

One of the main reasons Java fell out of favor for AWS Lambda is something called cold start latency. A “cold start” happens when a Lambda function is run for the first time or after it has been idle for a while. When this happens, AWS needs to set up a new environment to run the function. This setup time can make the function start more slowly.

In AWS Lambda, your code runs inside a container. When your function is invoked, AWS Lambda needs to set up this container before your code can run. This setup process includes:

• AWS Lambda allocates a container with the necessary resources (like memory and CPU) for your function,
• AWS Lambda initializes the runtime environment, which is the software that runs your code. This can be a language runtime like Python, or Java,
• AWS Lambda loads your function’s code into the container,
• If your code has any setup steps, like connecting to a database, these steps run during the cold start.

Java applications take longer to start up compared to other languages like Python or Node.js., Java’s cold start times are much slower. When a Java-based Lambda function is triggered, AWS needs to load the JVM into memory, starting up the entire JVM process, which is quite large and takes time to initialize. Java applications are built with multiple classes and libraries, and during a cold start, the JVM must load all these classes and libraries into memory. This process can be slow, especially if there are many dependencies or if the classes are large. The JVM uses Just-In-Time (JIT) compilation to convert Java bytecode into machine code at runtime. While this improves performance in the long run, it adds overhead during the initial startup, contributing to longer cold start times. Additionally, the JVM’s garbage collector, which automatically manages memory, also needs to be initialized, adding another step to the startup time. This delay can cause problems, especially for applications that need to respond quickly to user requests. As a result, developers began to prefer other languages that have faster start times for their AWS Lambda functions.

2. Memory Usage

Java’s higher memory footprint in comparison to languages like Python and Node.js is primarily due to several factors inherent to the Java Virtual Machine (JVM) and the language’s memory management model.

AWS Lambda charges based on the amount of memory allocated to a function and the time it runs. Since Java functions often require more memory, they can be more expensive to run compared to functions written in lighter-weight languages. For example, if a Java function requires 1GB of memory to run efficiently, it will cost more than a function written in Python or Node.js that can perform the same task with less memory. Moreover, higher memory usage can affect the performance of AWS Lambda functions. Each Lambda function is allocated CPU power proportional to the memory size chosen. If a Java function uses a large amount of memory, it will also receive more CPU power. However, this does not necessarily mean better performance, as the overhead of managing larger memory spaces can impact responsiveness and efficiency.

3. Other:

• Preference for Lightweight Solutions. Many developers prefer languages like Python, because they feel lighter and quicker for lambda functions, which are often used for quick tasks or integrations.
• Tutorials and Adoption. Python and JavaScript dominate lambda function tutorials and examples, contributing to their popularity over Java.
• Technical Challenges. Challenges like slow cold starts and managing code bundle sizes (especially with frameworks like Spring) have discouraged Java’s use for lambdas.

How to Bring Java Back to Favor in AWS Lambda (or rather how it regains popularity)?

1. Provisioned Concurrency
   
   To address the challenge of cold start latency in Java-based AWS Lambda functions, AWS introduced a feature called Provisioned Concurrency. This feature allows developers to pre-warm Lambda instances with a specified number of concurrent executions. Essentially, it keeps a set number of instances of your Lambda function ready to respond to incoming requests immediately.
   
   When you enable provisioned concurrency for a Lambda function, AWS Lambda initializes the specified number of execution environments (instances) and keeps them warm. These instances are ready to handle requests without the delay of cold starts because they are already initialized and loaded into memory.
   By pre-warming Lambda instances, provisioned concurrency drastically reduces the cold start latency that Java functions typically experience. This results in faster response times for your applications. Also with provisioned concurrency, you can predictably manage performance and ensure responsiveness for your applications. This is particularly beneficial for applications with strict latency requirements or fluctuating traffic patterns.
   
   To implement Provisioned Concurrency effectively, you should analyze your application’s traffic patterns and set an appropriate number of pre-warmed instances. This ensures that you are neither under-provisioned, which could lead to latency issues, nor over-provisioned, which could incur unnecessary costs.
   Imagine you have a Lambda function that processes orders for an online store. During regular hours, the traffic is moderate, but during special promotions, the traffic surges. To handle this, you can set Provisioned Concurrency to maintain a specific number of warm instances during the promotion period.

An example of how you can configure provisioned concurrency using AWS SDK for Java:

2. AWS Lambda SnapStart

When you enable SnapStart for a Java Lambda function, AWS Lambda creates and stores a snapshot of the initialized function environment. This snapshot includes the JVM state and loaded classes, among other dependencies. When a new request triggers the Lambda function, AWS Lambda can use this snapshot to quickly start a new execution environment without the need to reinitialize the JVM and load dependencies from scratch. This results in significantly reduced cold start times and faster response times for your applications.

An example of how you can enable SnapStart:

3. Optimized Java Frameworks

To optimize Java’s performance in AWS Lambda, developers can turn to lighter frameworks like Quarkus and Micronaut. These frameworks are designed to minimize startup time and memory usage, making them well-suited for serverless Java applications.

Quarkus: Quarkus is a Kubernetes-native Java framework tailored for GraalVM and OpenJDK HotSpot. It aims to significantly reduce memory consumption and boot times, making it ideal for serverless and cloud-native deployments.
Micronaut: Micronaut is another lightweight framework optimized for building modular and easily testable microservices and serverless applications. It supports ahead-of-time compilation, which reduces startup time and memory footprint.

Quarkus and Micronaut are modern Java frameworks that prioritize fast startup times and low memory footprint. They achieve this by employing techniques such as ahead-of-time (AOT) compilation, reactive programming models, and optimized dependency injection mechanisms. These frameworks are specifically tailored to address the challenges posed by serverless environments, where rapid scalability and quick response times are critical.

Advantages of Using Quarkus and Micronaut for Serverless Java Applications:

• Fast Startup Times — Quarkus and Micronaut leverage AOT compilation to generate native executable binaries or optimized bytecode, significantly reducing startup times compared to traditional JVM-based applications. This rapid startup ensures that Lambda functions written using these frameworks can respond quickly to incoming requests, minimizing cold start latency.
• Low Memory Footprint — By minimizing the number of dependencies and optimizing resource utilization, Quarkus and Micronaut require less memory to operate effectively. This efficiency translates into cost savings on AWS Lambda, where memory allocation directly impacts pricing and performance.
• Efficient Dependency Injection — Both frameworks offer lightweight and efficient dependency injection mechanisms, allowing developers to manage dependencies more effectively without compromising performance.
• Native Image Support — Both frameworks support compilation to native images using GraalVM, which further enhances startup times and reduces dependency on the JVM during runtime. Native images start almost instantly, making them suitable for short-lived serverless functions.

4. Custom Runtimes and GraalVM

AWS Lambda supports custom runtimes, which allow developers to use runtime environments tailored specifically for their applications. Instead of relying solely on the standard JVM, custom runtimes enable the use of optimized JVMs or even alternative runtimes that can enhance startup times and reduce memory usage. This customization can significantly improve the performance of Java-based Lambda functions.

Mentioned earlier GraalVM is a high-performance runtime that provides capabilities beyond those of traditional JVMs. One of its key features is the ability to compile Java applications into native images. These native images start up almost instantly, bypassing the need for JVM warm-up and initialization phases.

Java is slowly regaining popularity in AWS Lambda. AWS has introduced features like Provisioned Concurrency and AWS Lambda SnapStart, which specifically address Java’s historical challenges with cold start latency. Additionally, technologies like GraalVM have enabled Java applications to be compiled into native images, further reducing startup times and improving overall performance in serverless environments. This capability enhances Java’s competitiveness against languages known for their faster startup times.

The Java ecosystem is extensive and mature, offering developers a wide range of libraries, frameworks, and tools. This familiarity and richness of Java resources make it an attractive choice for developers who already have expertise in Java programming. Still, when it comes to small and straightforward AWS Lambda functions, Python tends to be the go-to choice.

The point is that it’s about balancing technical capabilities with practical considerations that best fit the project’s requirements and team preferences.

Words by Paulina Ksienżyk, Senior Engineer in Altimetrik Poland