At a point in the past, it was forecast that Java would die, but the JVM platform would be its legacy. And in fact, for a long time, the JVM has been tremendously successful. Wikipedia itself lists a bunch of languages that run on it, some of them close to Java e.g. Kotlin, some of them very remote e.g. Clojure.
But nowadays, the Cloud is becoming ubiquitous. Containerization is the way to go to alleviate some of the vendor lock-in issues. Kubernetes is a de facto platform. If a container needs to be killed for whatever reason (resource consumption, unhealthy, etc.), a new one needs to replace it as fast as possible. In that context, the JVM seems to be a dead-end: its startup time is huge in comparison to a native process. Likewise, it consumes a lot of memory that just increase the monthly bill.
What does that mean for us developers? Has all the time spent in learning the JVM ecosystem been invested with no hope of return over investment? Shall we need to invest even more time in new languages, frameworks, libraries, etc.? That is one possibility for sure. But we can also leverage our existing knowledge, and embrace the Cloud and containers ways with the help of some tools.
In this talk, I’ll create a simple URL shortener with a “standard” stack: Kotlin, JAX-RS and Hazelcast. Then, with the help of Quarkus and GraalVM, I’ll turn this application into a native executable with all Cloud/Container related work has been moved to the build process.
3. @nicolas_frankel
Hazelcast
HAZELCAST IMDG is an operational,
in-memory, distributed computing
platform that manages data using
in-memory storage and performs
execution for breakthrough
and scale.
HAZELCAST JET is the ultra
fast, application embeddable,
3rd generation stream
processing engine for low
latency batch and stream
processing.
7. @nicolas_frankel
Lift and Shift
The Cloud is just somebody else’s
computer
Relatively easy
• “Just” containerize the app
Run can be (a lot) more expensive than
on-premise!
• Worst case, all hell breaks loose
8. @nicolas_frankel
12-factors app
1. There should be exactly one codebase for a deployed service with the
codebase being used for many deployments.
2. All dependencies should be declared, with no implicit reliance on system
tools or libraries.
3. Configuration that varies between deployments should be stored in the
environment.
4. All backing services are treated as attached resources and attached
and detached by the execution environment.
5. The delivery pipeline should strictly consist of build, release, run.
6. Applications should be deployed as one or more stateless processes with
persisted data stored on a backing service.
9. @nicolas_frankel
12-factors app
7. Self-contained services should make themselves available to other
services by specified ports.
8. Concurrency is advocated by scaling individual processes.
9. Fast startup and shutdown are advocated for a more robust and
resilient system.
10. All environments should be as similar as possible.
11. Applications should produce logs as event streams and leave the
execution environment to aggregate.
12. Any needed admin tasks should be kept in source control and packaged
with the application.
10. @nicolas_frankel
A “standard” JVM web application
# Factor Issue
2 Declared deps App server is a dependency that is not
provided
3 Configuration Application server dependent
9 Fast startup The JVM takes a long time to startup
10 Streaming logs Write in different files
14. @nicolas_frankel
GraalVM
JVM platform by Oracle
Polyglot
• Java, Python, JavaScript, R, Ruby, C
Truffle
• Programming Language
implementation framework
15. @nicolas_frankel
Substrate VM
Create native executables from bytecode
Ahead-Of-Time compilation
Some limitations
• Needs to be configured for traditional
reflection
• Not cross-platform
• etc.
16. @nicolas_frankel
JVM vs. native executable
JVM Native
Memory consumption +++ +
Startup time +++ +
Write Once Run Everywhere ✓ ✘
Adapt to the workload ✓ ✘
19. @nicolas_frankel
The use-case: a URL shortener
Traditional approach
• Create a bijection between
⁃ Space(URL)
⁃ Space(short)
• Collisions handling
26. @nicolas_frankel
Recap: walk the middle path when possible
Use existing code
Use frameworks that know how to
leverage previous framework’s code
Better ROI 4TW!
27. @nicolas_frankel
Thanks for your attention!
https://blog.frankel.ch/
@nicolas_frankel
https://bit.ly/quarkus-hazelcast
https://bit.ly/url-shrtnr
Editor's Notes
@startuml
database "Hazelcast IMDG" as hz
actor User as user
node "JVM" {
node "Tomcat" {
interface HTTP
artifact "application.war" {
control "Controller" as ctrl
artifact "hazelcast-client.jar" as hzclient
}
artifact "servlet.jar" as servlet
artifact "jax-rs.jar" as jaxrs
artifact "catalina.jar" as catalina
}
}
user -right-> HTTP
HTTP -down- catalina
catalina - ctrl
ctrl - hzclient
hzclient - hz
ctrl .down.> servlet
catalina .down.> servlet
ctrl .down.> jaxrs
catalina .down.> jaxrs
@enduml
database "Hazelcast IMDG" as hz
actor User as user
node "JVM" {
interface HTTP
artifact "application.jar" {
control "Controller" as ctrl
file quarkus
file "quarkus-hazelcast-client" as hzclient
file "servlet" as servlet
file "jax-rs" as jaxrs
}
}
user -right-> HTTP
HTTP -down- quarkus
quarkus - ctrl
ctrl - hzclient
hzclient - hz
ctrl .down.> servlet
quarkus .down.> servlet
ctrl .down.> jaxrs
quarkus .down.> jaxrs
database "Hazelcast IMDG" as hz
actor User as user
interface HTTP
artifact "application.exe" {
control "Controller" as ctrl
file quarkus
file "quarkus-hazelcast-client" as hzclient
file "servlet" as servlet
file "jax-rs" as jaxrs
}
user -right-> HTTP
HTTP -down- quarkus
quarkus - ctrl
ctrl - hzclient
hzclient - hz
ctrl .down.> servlet
quarkus .down.> servlet
ctrl .down.> jaxrs
quarkus .down.> jaxrs