At the end there will be a container with only one executable and no shared libraries in it. The executable is written in java and the container starts in under 100ms.
Before getting into the details I want lay out the history that led to the creation of the talk.
In April I've attended the talk " Microservices und Containermanagement mit Mesosphere DC/OS" at the Java User Group Nürnberg. Someone from the it department of the German Federal Employment Agency told how they used Mesophere to manage their container. He mentioned that the many Java microservices they have don't require much CPU while running but require a lot of CPU on startup. To get a fast startup of the java container but restrict the CPU usage to what is needed on runtime they created a container that sleeps 3 minutes and then exits. This sleeping container is allocated a lot of CPU resources and added to the same pod where the java container is. The java container is then allowed to use the left over CPU resource of the sleeping container.
In October I've read about the Micronaut framework. A new framework for developing microservices. One of the advantages they claim is that they move reflection and initialization from startup to compile time. Thus applications developed with Micronaut should start faster than those developed with other frameworks.
Also in October I've attended a talk about Serverless with AWS. The concept of splitting your code into functions and you pay nothing when the function isn't executed is cool. But when a function is executed you pay from the second your code is going prepared for running. So every second you take to initialize costs you real money (OK not much and there is caching so that often used functions won't ruin you, but still initialization costs money).
While these three events emphasize how important fast and low costing startup is, the real incentive to create this talk came at another conference. I've showed how to create a container that consists only of one static compiled go binary and how small such a container can get. Then I've claimed that this isn't possible with Java. It didn't took long and someone pointed out that this is wrong thanks to GraalVM.
So I've decided to give myself a try in developing a small microservice that would be compiled to a native binary with GraalVM.
This post is part of a series:
- Native x86 Microservice in Java
- The Java program
- The
native executable
- The container