Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
It's been quite some time since I blogged. I was busy writing the book on GraalVM. It was an awesome experience writing my first book. Never thought it will be so intense though :-D but enjoyed every bit of it
Before I get into the actual topic, let me introduce GraalVM. Here are some blogs on GraalVM, I had published before.
In my previous blog post, I documented how to take a Java Spring Boot application and convert it into a serverless function, which can be run in AWS Lambda.
Anyone who's done this before knows that cold starts are a big downside - Java and Spring Boot are not known for their speedy startup times, and a typical full fat Spring Boot-converted lambda can take anything from 10 to 90 seconds depending on how much memory and CPU you allocate it. This may force you to over-provision them to compensate for the cold starts, but that's a pretty expensive sledgehammer. There is always provisioned concurrency, but that doesn't work out much cheaper either (and negates the responsive scalability of lambda as you have to anticipate how many you'll need in advance).
In the era of containers (the "Docker Age") Java still keeps alive, being struggling for it or not. Java has always been (in)famous regarding its performance, most of because of the abstraction layers between the code and the real machine, the cost of being multi-platform (Write once, run anywhere — remember this?), with a JVM in-between (JVM: software machine that simulates what a real machine does).
You may also like: All About Spring Boot [Tutorials and Articles]
Nowadays, with the Microservice Architecture, perhaps it does not make sense anymore, nor any advantage, build something multi-platform (interpreted) for something that will always run on the same place and platform (the Docker Container — Linux environment). Portability is now less relevant (maybe more than ever), those extra level of abstraction is not important.
Porting existing JavaScript code from Nashorn to GraalVM can be a challenge. This article focus on a multi-threading issue we got into when we ported SwiftMQ Stream scripts generated from Flow Director.
If you register an asynchronous callback on a Java class and this callback is invoked while you are still within the execution of the same JS script, you have multi-threaded access, even if you immediately schedule the processing of the callback in an event queue. Nashorn doesn’t check this, but GraalVM does and throws an exception. So any script with such callbacks will not work on GraalVM.
A faster startup and smaller memory footprint always matter in Kubernetes due to the expense of running thousands of application pods and the cost savings of doing it with fewer worker nodes and other resources. Memory is more important than throughput on containerized microservices on Kubernetes because:
This significantly impacts serverless function development and the Java deployment model. This is because many enterprise developers chose alternatives such as Go, Python, and Nodejs to overcome the performance bottleneck—until now, thanks to Quarkus, a new Kubernetes-native Java stack. This article explains how to optimize Java performance to run serverless functions on Kubernetes using Quarkus.
The Spring Native project provides support for packaging Spring applications as native images using GraalVM.
Compared to JVM executables, native images have faster startup times (<100 ms) and lower memory consumption. However, building a native image requires more time than a JVM-based one.
Function-as-a-Service or Serverless is the most economical way to run code and use the cloud resources to the minimum. The serverless approach runs the code when a request is received. The code boots up, executes, handles the requests, and shuts down. Thus, utilizing the cloud resources to the optimum. This provides a highly available, scalable architecture, at the most optimal costs. However, serverless architecture demands a faster boot, quicker execution, and shutdown.
GraalVM native images (ahead of time) is the best runtime. GraalVM native images have a very small footprint, they are fast to boot and they come with embedded VM (Substrate VM).
Early adopters for Cloud-Native (microservices, serverless) are now moving to its next wave called v2.x., leveraging the maturity, learnings, and identified shortfalls to design next-level stuff.
Let's recap few purposes of going cloud-native that we will relate here:
Native cloud applications use services and infrastructure provided by AWS, Microsoft Azure, and Google Cloud among others. Essentially, this means you can code, test, maintain, and run your app all in the cloud.
This approach gives developers an opportunity to:
The Google Drive component provides access to the Google Drive file storage service via the Google Drive Web APIs.
Google Drive uses the OAuth 2.0 protocol for authenticating a Google account and authorizing access to user data. Before you can use this component, you will need to create an account and generate OAuth credentials. Credentials comprise of a clientId, clientSecret, and a refreshToken. A handy resource for generating a long-lived refreshToken is the OAuth playground.
Java is becoming very progressive with a new release policy and we receive regularly every 6 month new features, enhancements or just previews to test it out and write them back our feedback that can be taken into account in further development.
The second line might be even more interesting. It's GraalVM Project that especially contains a new C2 JIT Compiler and multi-language support based on Truffle Framework. There is one more technology that deserves our attention — GraalVM Native-Image. Native image is a utility for converting Java applications into fully compiled binary code which is called native-image. The process of creating a native-image is called ahead-of-time compilation.
I have been exploring and playing around with the Apache OpenNLP library after a bit of convincing. For those who are not aware of it, it’s an Apache project, supporters of F/OSS Java projects for the last two decades or so. I found their command line interface pretty simple to use, and it is a great learning tool for beginning to work with Natural Language Processing (NLP).
To preface this article, make sure that you're familiar with Jupyter Notebooks. If you are not, have a look at this video these articles: [1] or [2]. For using the CLI, I’ll refer you to this post.
The GraalVM compiler is a replacement to HotSpot’s server-side JIT compiler, widely known as the C2 compiler. It is written in Java with the goal of better performance compared to the C2 compiler. New changes, starting with Java 9, mean that we can now plug in our own hand-written C2 compiler into the JVM thanks to JVMCI. The researchers and engineers at Oracle Labs have created a variant of JDK8 with JVMCI enabled, which can be used to build the GraalVM compiler. The GraalVM compiler is open source and is available on GitHub (along with the HotSpot JVMCI sources needed to build the GraalVM compiler). This gives us the ability to fork/clone it and build our own version of the GraalVM compiler.
In this post, we are going to build the GraalVM compiler with JDK8 on CircleCI. The resulting artifacts are going to be:
Hi Roberto, tell us who you are and what lead you into microservices?
Hi! I’m Roberto Cortez, Java Champion, JUG Leader of the Coimbra JUG and Founder of the JNation Conference in Portugal.
Recently I was working on a small project to build a simple browser-based app using Quarkus, JQuery, and Postgresql. The focus was more on learning Quarkus, while the others were complimentary. I was interested to get a first-hand experience on Quarkus and Graal VM. Some readers might be new with these words so let me start with a small introduction on these two projects.
Quarkus is an open source project working with a container-first philosophy to build cloud-native Java-based applications using a microservice architecture. It brings along significant improvement on app booting (a notorious area for improvement for Java-based applications) by build time meta-data processing and most importantly building standalone native images using Graal/Substrate VM. Graal VM applies a technique to statically analyze the classes to determine which classes and methods are reachable and will be used during application execution. Then it passes all this reachable code as the input to the GraalVM compiler which ahead-of-time (AOT) compiles it to the native binary. The native binary runs on a different VM (Substrate VM) that manages runtime components like de-optimizer, garbage collector, thread scheduling, etc.
A few weeks ago, Red Hat introduced Quarkus, which is a "next-generation Kubernetes-native Java framework" that is available as open source. Quarkus promises really fast boot times and low memory usages. This makes Quarkus a perfect fit for Java workloads running as microservices on Kubernetes as well as Java workloads running as serverless functions.
Read the article, "Why Quarkus" to learn how Quarkus works. In a nutshell, Quarkus compiles Java source code in native binaries via GraalVM. The Quarkus framework helps developers to easily build applications that can leverage the GraalVM benefits.
Continuing from the previous post, Two Years in the Life of AI, ML, DL, and Java, where I expressed my motivation, I mentioned our discussions, one of the discussions was that you can write in languages like Python, R, and Julia in JuPyteR notebooks. Most were not aware that you can also write Java and Scala in addition to Python, SQL, etc. with the help of Apache Zeppelin notebooks. And so, I wanted to share something to broaden everyone’s awareness of Apache Zeppelin and its features. The project itself is written in Java and is an open architecture, which means that Zeppelin can support anything as long as an interpreter for that thing has been provided.
In case I have lost some of you, here’s what I meant by JuPyteR notebooks and writing notebooks in different languages. Also, have a look at the list of kernels supported by JuPyteR notebook. In this post, however, we are covering Apache Zeppelin, how to get it to work, and how to use a couple of notes in the Zeppelin environment.
