Quarkus Supersonic Subatomic Java - DeveloperMarch · 2019-05-17 · • Undertow 3 will use Netty...

transcript

Quarkus Supersonic Subatomic Java Stuart Douglas, Principal Software Engineer Red Hat

• Employed by Red Hat since 2011 • Quarkus Co-Founder • Undertow Founder • Core contributor to WildFly • Servlet Spec Co-Lead

About Me

@stuartwdouglas

github.com/stuartwdouglas

Quarkus: A Java Stack Designed for Cloud Native Development

Quark a subatomic particle carrying a fractional electric charge And us (the heart of software development)

WHAT’S

Quarkus

• A standards based platform that prioritises developer experience, startup speed and memory usage

• Optimised for cloud use cases • Built on mature libraries such as

Hibernate and RESTeasy • Allows for compilation to native code via

GraalVM

What is it?

• Easy to get started • Familiar API’s • Unified Configuration • Convention over configuration • Focus on documentation • Remove boilerplate

Designed for Developers

Developer Mode mvn compile quarkus:dev

• Lets you connect to a container running

in dev mode in the cloud • Changes made locally take effect

instantly

Cloud Native Development

mvn compile quarkus:remote-dev

Evolving Java For Containers and Serverless

ENTERPRISE JAVA WAS DESIGNED FOR 3-TIER ARCHITECTURE

APPLICATION SERVER / JVM

HTML Javascript Web

Cart Catalog Inventory

Promo Ratings Orders

Data Access

Presentation Logic

Business Logic

Data Access Logic

OPERATING SYSTEM

HOW APPLICATION SERVERS DEPLOYED JAVA APPS

APPLICATION SERVER / JVM

HTML Javascript Web

Data Access

OPERATING SYSTEM

HTML Javascript Web

Data Access

Microservices changed how we write apps

Microservice

Kubernetes

And serverless/FAAS will change it even more

Function

The hidden truth about Java in containers

CONTAINER ORCHESTRATION

Node Node Node

Traditional Cloud-Native Java Stack

NodeJS

Go Go Go

https://developers.redhat.com/blog/2017/03/14/java - inside-docker/

The hidden truth about Java in contains

Total Memory (RSS)

Metaspace Heap Off Heap

Only the heap is available to your application at runtime

THE HIDDEN TRUTH ABOUT JAVA IN CONTAINERS

Node Node Node

NodeJS

Go Go Go

https://developers.redhat.com/blog/2017/03/14/java - inside-docker/

Hotspot Heap

• Complex Management Infrastructure • Remote Management • Hot Deployment of Applications • Full Java EE Stack • Patching

You are deploying features you don’t need

But you still pay for them in memory usage and startup time

• Still one of the most popular languages • Java has a massive amount of mature and

tested frameworks and libraries • Companies have made a massive

investment in Java • These problems are not with Java itself, but

they way it has traditionally been used

Why Java?

Comparisons

100x faster startup, 10% of the memory in native mode

5 x faster and ½ the of the memory on Hotspot/ OpenJ DK

Native Compilation?

$ ls -l hibernate-orm-resteasy-1.0-SNAPSHOT-runner -rwxr-xr-x 1 stuart staff 54245792 17 Apr 12:43 hibe...

INFO Quarkus 0.13.2 started in 0.029s. Listening on: http://127.0.0.1:8080 INFO Installed features: [agroal, cdi, hibernate-orm, jdbc-postgresql, narayana-jta, resteasy, resteasy-jsonb]

• Quarkus solves the Java density and startup time problems

• This mean less memory usage and lower costs

• Native mode takes it even further

Quarkus and the cloud

Developer Experience

• CDI • JAX-RS • JPA • Bean Validation • Websockets • Transactions • Servlet

Familiar Standards

• Config • REST Client • Health Check • Reactive Streams • OpenAPI • OpenTracing • ...

• We aim to be standards based as much as possible

• Unless following the standard unduly impacts: • Developer experience • Startup Time • Memory usage

• Then we will innovate and try and change the standard

Approach to Standards

• We are not implementing EJB, but will add similar functionality

• @TransactionAttribute -> @Transactional

• Remote Interfaces -> GRPC • Declarative Security -> CDI Interceptor

No EJB

JPA Automatic Activation

• No persistence.xml required • If you include JPA, have a datasource, and

some Entities we auto configure it • No Resource Producer fields required

Arc: Build Time CDI

• Arc is a new implementation of CDI that resolves all injection points at build time

• Mostly reflection free • Fast startup and low memory use

• Portable Extensions allow you to modify any application metadata at startup

• This is not compatible with build time processing

• We have implemented our own build time extension mechanism, and once it has matured we will aim to standardise it

Example: CDI Portable Extensions

• Panache (Simplified JPA) • Vert.x • Apache Camel • Apache Kafka • Kotlin Support • Scheduling

More than just standards

UNIFIES IMPERATIVE AND REACTIVE

Combine both Reactive and imperative development in the same application Inject the E ventB us or the Vertx context Use the technology that fits your use-case

How Does it Work?

QUARKUS BUILD PROCESS

Compile Provision Augment Compile to Native

• As much processing is possible is done at

build time • Don’t do annotation or descriptor

processing at boot time • Result is written out as generated

bytecode

Build Process

• Almost all Quarkus functionality is

implemented as extensions • Extensions consist of two parts, runtime

and deployment time • Only the runtime part ends up in the

final application

Extensions

Anatomy of an Extension

Deployment • Processes annotations,

config and other metadata • Outputs generated bytecode

to start the runtime components

• Injection based • No knowledge of bytecode

required

Runtime • Runs the bytecode

generated at build time • Starts runtime services • Should only contain what is

needed at runtime

Polyglot, Native or JVM, Embeddable

Quarkus Native Deployment

Node Node

Traditional Cloud -Native Java Stack

Quarkus Quarkus Quarkus

Quarkus Quarkus

Quarkus Quarkus Quarkus Quarkus Quarkus

JVM CI

S ulong (LLVM)

Truffle

Graal Compiler

S ubstrate VM

J ava HotS pot VM

• Compiles Java applications to a native executable

• Has some limitations that make it hard to use out of the box

• Quarkus works around those limitations so you don’t have to

GraalVM

• Closed World, no dynamic class loading • All reflection usage must be declared at

build time • Various other things unsupported

Limitations

Developing Native Applications with SubstrateVM Can be Painful

Quarkus handles this for you

$ mvn quarkus:native-image

Building Native Images

• Quarkus will analyse your application, and give GraalVM all the information it needs to build an executable

• Also provides @RegisterForReflection

Quarkus makes Java run better in Serverless and Container Environments

• Quarkus is still a very young project • We have a lot planned

Future Plans

• We are looking at ways to make it easy to discover and consume third party extension

• There should be no real difference between extensions provided by the core team and third party ones

Extension Ecosystem

• Building a Quarkus app is not really part of the build, it happens after

• It should be possible to easily update running apps to latest version, without rebuilding

Post Build Updates

• Undertow 3 will use Netty as the underlying transport

• This will allow us to share resources better, resulting in lower memory usage

• Also allows Vert.x and Undertow endpoints to share a port

I/O Alignment

http://quarkus.io

Resources

@stuartwdouglas

github.com/stuartwdouglas

github.com/quarkusio

@quarkusio

Quarkus Supersonic Subatomic Java - DeveloperMarch · 2019-05-17 · • Undertow 3 will use Netty...

Documents