I continue to work on my Opentelemetry demo. Its main idea is to showcase traces across various technology stacks, including asynchronous communication via an MQTT queue. This week, I added a couple of components and changed the architecture. Here are some noteworthy learnings; note that some of them might not be entirely connected to OpenTelemetry. Here’s an updated diagram. New components appear in violet, and updated components appear in green.

So far, we have looked at how well Spring Boot and Micronaut integrate GraalVM native image extension. In this post, I’ll focus on Quarkus: A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards. Creating a new project Just as Spring Boot and Micronaut, Quarkus provides options to create new projects: A dedicated quarkus CLIA Web UI Quarkus offers a definite improvement over its competitors.

Last week, I wrote a native web app that queried the Marvel API using Spring Boot. This week, I want to do the same with the Micronaut framework. Creating a new project Micronaut offers two options to create a new project: A web UI: As for Spring Initializr, it provides several features: Preview the project before you download itShare the configurationAn API I do like that you can check the impact that the added features have on the POM.

The Cloud has enabled a lot of new usages that were not possible before. Among them stands Serverless: Serverless computing is a cloud computing execution model in which the cloud provider allocates machine resources on demand, taking care of the servers on behalf of their customers. Serverless computing does not hold resources in volatile memory; computing is rather done in short bursts with the results persisted to storage.

Some time ago, I read a post describing how to run a serverless Kotlin function on OpenFaaS. While the content is technically correct, I believe the concept itself is very wrong. Such posts can lead people to make ill-advised decisions: 'because we can' is hardly a winning strategy. in this post, I’d like to first explain why the JVM platform is a bad idea for FaaS. Then, I’ll proceed to propose alternatives to use Kotlin nonetheless.

I’ve been playing with GraalVM AOT compilation capability since I became aware of it. As a long-time Spring aficionado, I carefully monitored the efforts that the engineers at Tanzu have put into making Spring AOT-compatible. Recently, they announced the beta version of the integration. In this post, I want to check how easy it is to produce a (working!) Docker image from an existing Spring Boot application. Introduction GraalVM provides many different features.

One of my current talks is about creating a Kubernetes operator in Java. I demo it step by step. In the later steps, I’m using GraalVM native image to create a native executable. In that regard, some libraries are not compatible with the native image creation process. Several options are available to make them work anyway. One of the options is to substitute incompatible code with compatible one. In the above post, I describe how to use those substitutions. I thought I had it right.

In the first post of this series, we described the concept behind a Kubernetes controller. In short, it’s just a plain control loop that reconciles the desired state of the cluster with its current state. In the second post, we implemented a sidecar controller in Java. This third and last post will be focused on where to deploy this Java controller and how to improve it to be on par with a Go one. Running outside the cluster or inside?

I’ve been following GraalVM with a lot of interest. One of the interesting areas is its ability to compile bytecode Ahead-Of-Time, and create a native image. Such images have a lot of advantages, including small size, no dependency on a JRE, etc. However, AOT has some limitations. In particular, the native image executable cannot compile what it doesn’t know about. This post aims to describe how to configure the compilation process when code is using reflection.

Last week was the release of Oracle’s GraalVM. As stated on the website: GraalVM is a universal virtual machine for running applications written in JavaScript, Python 3, Ruby, R, JVM-based languages like Java, Scala, Kotlin, and LLVM-based languages such as C and C++. GraalVM removes the isolation between programming languages and enables interoperability in a shared runtime. It can run either standalone or in the context of OpenJDK, Node.js, Oracle Database, or MySQL.