The new titanium cloud service has shared 742 technical dry goods for you
Achieve faster startup and smaller memory footprint to run serverless functions on Kubernetes.
Faster startup and smaller memory footprint are always important in Kubernetes due to the expense of running thousands of application pods and saving costs by using fewer worker nodes and other resources. On containerized microservices on Kubernetes, memory is more important than throughput because:
l It is more expensive due to eternity (unlike CPU cycles).
l Microservices multiply overhead costs.
l A single application becomes N microservices (for example, 20 microservices ≈ 20GB)
This significantly impacts serverless feature development and Java deployment models. That's because many enterprise developers have chosen alternatives like Go, Python, and Nodejs to overcome performance bottlenecks -- until now, thanks to Quarkus, a new Kubernetes-native Java stack. This article describes how to optimize Java performance to run serverless functions on Kubernetes using Quarkus.
container-first design
Traditional frameworks in the Java ecosystem come at a price in terms of the memory and startup time required to initialize those frameworks, including configuration processing, classpath scanning, class loading, annotation processing, and building a metamodel of the world, which frameworks require. This is multiplied again and again for different frameworks.
Quarkus helps address these Java performance issues by "left-shifting" nearly all overhead to the build phase. By doing code and framework analysis, bytecode transformation, and dynamic metamodel generation only once at build time, you end up with a highly optimized runtime executable that starts super fast and doesn't require all the memory of a traditional launch , because the work is done once in the build phase.
What's more, Quarkus allows you to build native executables with performance advantages, including amazingly fast startup times and very small resident set size (RSS) memory, enabling instant scaling and high Density memory utilization - native Java stack.
This is a quick example of how to use Quarkus to build a native executable from a Java serverless functional project.
01
Create a Quarkus serverless Maven project
This command generates a Quarkus project (such as quarkus-serverless-native) to create a simple function:
02
Build native executables
You need a GraalVM to build native executables for Java applications. You can choose any GraalVM distribution, such as Oracle GraalVM Community Edition (CE) and Mandrel (a downstream distribution of Oracle GraalVM CE). Mandrel is designed to support building Quarkus native executables on OpenJDK 11.
Open pom.xml, you will find this native configuration file. You'll use this to build native executables:
Note: You can install GraalVM or the Mandrel distribution locally. You can also download the Mandrel container image to build it (like I did), so you'll need a container engine (e.g. Docker) running locally.
Assuming you have already started the container runtime, run one of the following Maven commands.
For Docker:
For Podman:
The output should end with BUILD SUCCESS.
To run native executables directly without a Java Virtual Machine (JVM):
The output will look like this:
Supersonic! Startup time is 19 ms. Times may vary depending on your environment.
It also has extremely low memory usage, as reported by the Linux ps utility. While the app is running, run this command in another terminal:
You should see something like:
This process uses approximately 11MB of memory (RSS). Quite compact!
Note: RSS and memory usage for any application (including Quarkus) will vary based on your specific environment and will increase as the application experience loads.
You can also access the function using the REST API. Then the output should be Hello RESTEasy:
03
Deploy the function to the Knative service
If you haven't already, create a namespace (e.g. quarkus-serverless-native) on OKD (OpenShift Kubernetes Distribution) to deploy this native executable as a serverless function. Then add a quarkus-openshift extension for Knative service deployment:
Add the following variables in src/main/resources/application.properties to configure Knative and Kubernetes resources:
Build a native executable, then deploy it directly to the OLD cluster:
Note: Make sure to log in to the correct project (e.g. quarkus-serverless-native) using the oc login command ahead of time.
The output should end with BUILD SUCCESS. It takes a few minutes for the native binary to build and deploy the new Knative service. After successfully creating the service, you should see the Knative service (KSVC) and revision (REV) using the kubectl or oc command tools:
04
Access native executable functions
Retrieve the serverless function's endpoint by running the following kubectl command:
The output should look like this:
Access the route URL with the curl command:
In less than a second, you'll get the same result as locally:
When you visit the Quarkus running pods logs in the OLD cluster, you will see native executables running as Knative services.
What's next?
You can use the GraalVM distribution to optimize Java serverless functions and deploy them as serverless functions on Knative and Kubernetes. Quarkus achieves this kind of performance optimization with simple configuration in common microservices.
Original link:
https://opensource.com/article/21/6/java-serverless-functions-kubernetes
recommended reading
recommended video