Want to start series on Serverless Java on AWS Lambda and all the details, what frameworks to use, what to expect from this approach, is it even sustainable in real life and how to ‘cook’ your Java for serverless.

This series will be useful for any Java Serverless application, doesn’t matter is it AWS, GCP, Azure, etc. All experience, approaches, tooling, tutorials, code and best practices are applicable in any situation only difference is that all deploy details will be against AWS Lambda and internals of frameworks are specific for AWS Lambda API.

This is intro article in a big series that will overview serverless via frameworks like Micronaut, Quarkus, Spring, etc.

This article is an overview of techniques and tools that will be used for whole series.

Serverless overview

Let’s dig a bit into domain and talk about serverless architecture.

intro about what serverless is:

Serverless is a cloud computing execution model that provisions computing resources on demand, and offloads all responsibility for common infrastructure management tasks (e.g., scaling, scheduling, patching, provisioning, etc.) to cloud providers and tools, allowing engineers to focus their time and effort on the business logic specific to their applications or process.

— IBM

The main thing about serverless is that serverless resources on demand should be provided as fast as possible and returned to serverless provider also as fast as possible, we are talking about money per millisecond of execution time here.

Such paradigm require our serverless function to boostrap and execute as fast as possible.

Let’s move to Java keeping such paradigm in mind.

Is it even a thing in Java?

Java known for fast performance in runtime due to JIT and its optimizations, but what about bootstrap? As everyone known most of Java frameworks and the most popular one Spring lack this feature and kinda known for slow cold starts. So should we like do Lambda without frameworks with our bare hands?

Don’t thing so.

Of course, you can do all by hand and without frameworks, but when we are talking about flexibility, about multiple development teams making serverless applications in company, we are talking about consistency and common approaches for out code base.

This is where frameworks come in handy, they provide tools and approaches, so we can’t avoid them and their ecosystem.

You can try lazy initialization for components in some frameworks that are eager by default, you can try –sharedclass, provide manual configuration for components, do tons of hacks and still be slow. Those approaches may be useful in server-side workload, but not enough in serverless one.

I don’t thing that just by running traditional JVM applications is sustainable in any serverless workload.

Our goal is to make Java application boostrap faster, much faster. We are talking about AOT approach here compared to JIT.

Java known for one of the best tooling across all platforms and new tools appear to help you overcome some difficulties like slow cold starts. This is where AOT comes in handy.

Ahead of Time (AOT) Compilation is a helpful feature for your development lifecycle or distribution time. It benefits you when you know beforehand what your target device is going to be at application execution time. The AOT feature provides the following benefits:

  • No additional compilation time is done when running your application.
  • No just-in-time (JIT) bugs encountered due to compilation for the target device, because this step is skipped with AOT compilation.
  • Your final code, executing on the target device, can be tested as-is before you deliver it to end-users.

— Intel

We are on correct path, lets dig into Java and AOT.

Holy GraalVM of AOT

Most of you already heard, some of you already tried GraalVM but still here is little about GraalVM:

Native Image is a technology to ahead-of-time compile Java code to a standalone executable, called a native image. This executable includes the application classes, classes from its dependencies, runtime library classes, and statically linked native code from JDK. It does not run on the Java VM, but includes necessary components like memory management, thread scheduling, and so on from a different runtime system, called “Substrate VM”. Substrate VM is the name for the runtime components (like the deoptimizer, garbage collector, thread scheduling etc.). The resulting program has faster startup time and lower runtime memory overhead compared to a JVM.

— GraalVM

AOT vs JIT

This approach will allow us to minimize boostrap and memory footprint time to minimal compared to traditional applications running in JVM.

This is what we are looking for and this is what we will be using in future articles in series.

The Cloud

All tutorials and examples will be against AWS Lambda as cloud provider, because I find it mostly used compared to other cloud providers. Most frameworks across JVM ecosystem also try to support integration with AWS as first-citizen cloud provider.

All approaches, techniques and examples are applicable for any Serverless Cloud Provider and AWS here will be used mostly as our benchmark stand.

The Language

Of course you can write serverless via Golang or some other one, but is it even necessary? Can you do it with Java? Can you?

This is the question I want to answer in this series.

This series will focus on Java as language as first-citizen language for JVM ecosystem, still you can investigate documentation provided for frameworks that will be highlighted in series and port solutions on Kotlin if it is applicable.

The Frameworks

As it was previous mentioned enterprise development without consistency is a failure. Developers need good tooling, common approaches for server side and serverless applications, DI and IoC like ones of the most fundamental in Java ecosystem, simple setup and quick build type, easy testing, integration with various external datasource configuration and configuration via ENV\System properties, ton of goodies.

You can’t image building software in JVM ecosystem without frameworks now and that’s okay, we just need to choose one and make things work. This is the most interesting which one to choose, so you won’t be bashing your head on the wall in the next few years when you find out that your decision wasn’t good one.

Hope in the end we could see in which conditions each of candidates shines the most.

This series will compare most mature and widely spread frameworks that are production ready, such as Micronaut, Quarkus, Spring, etc.

The Build Tool

This series will focus on using Gradle as build tool for Java applications, cause let’s face the truth, Maven is kinda too verbose and is not that flexible.

You can hate Gradle, but this is how setup for any new microservice or serverless application should work in 2021 in muy opinion. If you want to use best tooling, you stick with Gradle, that’s what I figured out for my self.

The CI/CD

Series will overview how our pipeline can be managed and build for deploying such applications, what will be the most optimal approaches for different frameworks and tools overview that is available building applications via different frameworks.

Series will also focus on how to deploy serverless applications, usability and flexibility of such pipelines.

Information about my thoughts on this topic will be collected into separate aggregated table with advantages/disadvantages of each approach.

Benchmarking

In the end, there will be benchmark for all serverless applications, all frameworks will be compared by their cold and hot startup time, execution time in different scenarios, etc.

Conclusion

The only reasonable serverless approach with Java is GraalVM native image.

This series will highlight serverless (AWS Lambda) on different production ready frameworks, with detailed overview of approach, comparing flexibility, tooling, execution time, build time, bootstrap time, build pipelines, etc.

Article aims to provide guide for each Framework how-to build serverless with:

  • Simple setup
  • Fastest bootstrap
  • Fastest execution time
  • Transparent CI/CD

Don’t forget about code examples for each approach.

This series aims to help you decide about Stack for your Java serverless setup.

In the end we will see is it possible to build simple, fast and reliable serverless application on Java or not quite so.

Stay tuned.