In November 2018 I've attended the SOFTWARE ENGINEERING CAMP and gave the talk "Native x86 Microservice in Java". This series of blog posts is an extended version of the talk.
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: