While Java was evolving at its own pace, compute has also evolved dramatically. In previous years, it took a long time to actually focus on the business logic that addresses the customer's requirements. For example, initially we had to procure bare metal servers, provision them, and ultimately start prototyping and building applications. The level of abstraction was very low; however, the focus on business logic came way later in the magnitude of months, if not in years. That changed when we moved to Virtual Machines (VM). VMs provided some level of abstraction while running in production. But the development environment was still not in parity with VMs. Then came Containers which provided a great level of abstraction where developers can focus on building business logic sooner than with other compute abstractions.

In 2016, AWS introduced Lambda functions as a Serverless option. There are still servers involved, but AWS owned the heavy lifting of maintaining those servers for you so that you focus on just writing business logic, thus the highest level of abstraction and developers focus on directly writing and deploying business logic as Lambda functions.

Today AWS Lambda runs on Firecracker microVM and provides:

• Continuous scaling
• Built-in fault tolerance
• Pay per use

However, for Java, there are challenges that AWS Lambda had to deal with because of the way Java was built from the ground up and the way AWS Lambda works. Let's understand those challenges.