Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What's the Magic Behind Quarkus

What's the Magic Behind Quarkus

Quarkus is revolutionizing the way that we develop Java applications for the cloud-native era. Do you want to learn why Quarkus is different from everything else? Then come and join us on this session to take a look at how Quarkus works and the techniques it uses to achieve its dramatic startup speed improvements. As part of this we will also cover the Quarkus extension API, so you can see how to write your own extensions that take advantage of Quarkus’ unique architecture.

Edson Yanaga

July 24, 2019
Tweet

More Decks by Edson Yanaga

Other Decks in Technology

Transcript

  1. !1
    What’s the magic behind Quarkus?
    Edson Yanaga, Red Hat
    @yanaga

    View full-size slide

  2. !2
    A stack to write Java
    apps
    Cloud Native, Microservices, Serverless

    View full-size slide

  3. WHY QUARKUS?

    View full-size slide

  4. From monolith to...
    !4
    ● 1 monolith ≈ 20 microservices ≈ 200 functions
    ● Scale to 1 vs scale to 0
    ● Start up time
    MONOLITH
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    MICRO
    SERVICE
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F
    F F
    F
    F
    F
    F
    F
    F
    F
    F

    View full-size slide

  5. !5
    Why go through this pain?
    Agility, Scalability, Faster Business Reactivity
    Container platform
    App 1
    Data
    App 2
    Data
    App 3
    Data
    App 4 App 5
    Data

    View full-size slide

  6. ● Startup overhead
    ○ # of classes, bytecode, JIT
    ● Memory overhead
    ○ # of classes, metadata, compilation
    !6
    The hidden truth about Java + containers
    RSS
    Heap Metaspace off-heap

    View full-size slide

  7. !7
    Container platform
    Node
    NodeJS
    NodeJS
    NodeJS
    NodeJS
    NodeJS
    NodeJS
    NodeJS
    Node
    Go Go
    Go Go
    Go Go
    Go Go
    Go Go
    Go Go
    Go Go
    Node
    HotSpot Heap
    HotSpot Heap
    HotSpot Heap
    HotSpot Heap
    The hidden truth about Java + containers

    View full-size slide

  8. WHAT IS QUARKUS?
    QUARK: elementary particle / US: heart of computer science

    View full-size slide

  9. !9
    A cohesive platform for optimized developer joy:
    ● Based on standards, but not limited
    ● Unified configuration
    ● Zero config, live reload in the blink of an eye
    ● Streamlined code for the 80% common usages,
    flexible for the 20%
    ● No hassle native executable generation
    Benefit No. 1: Developer Joy

    View full-size slide

  10. !10
    Benefit No. 2: Supersonic Subatomic Java
    Memory (RSS) in Megabytes
    Quarkus + GraalVM
    13 MB
    Quarkus + OpenJDK
    74 MB
    Traditional Cloud-Native Stack
    140 MB
    REST

    View full-size slide

  11. !11
    Benefit No. 2: Supersonic Subatomic Java
    Memory (RSS) in Megabytes
    REST + CRUD
    Quarkus + GraalVM
    35 MB
    Quarkus + OpenJDK
    130 MB
    Traditional Cloud-Native Stack
    218 MB

    View full-size slide

  12. !12
    Benefit No. 2: Supersonic Subatomic Java
    Boot + First Response Time (in seconds)
    Quarkus + GraalVM 0.014 Seconds
    REST
    REST + CRUD
    Quarkus + OpenJDK 0.75 Seconds
    Quarkus + GraalVM 0.055 Seconds
    Quarkus + OpenJDK 2.5 Seconds
    Traditional Cloud-Native Stack 9.5 Seconds
    Traditional Cloud-Native Stack 4.3 Seconds
    Time to first response

    View full-size slide

  13. !13
    Benefit No. 3: Unifies Imperative and Reactive
    ● Combine both Reactive and imperative development in the same application
    ● Use the technology that fits your use-case
    ● Key for reactive systems based on event driven apps
    @Inject
    SayService say;
    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
    return say.hello();
    }
    @Inject @Stream(”kafka”)
    Publisher reactiveSay;
    @GET
    @Produces(MediaType.SERVER_SENT_EVENTS)
    public Publisher stream() {
    return reactiveSay;
    }

    View full-size slide

  14. !14
    Benefit No. 4: Best of Breed Frameworks & Standards
    Eclipse Vert.x Hibernate RESTEasy Apache Camel Eclipse MicroProfile Netty
    Kubernetes OpenShift Jaeger Prometheus Apache Kafka Infinispan

    View full-size slide

  15. GraalVM
    You keep using that word.
    I do not think it means what you think it means.
    The Enabler

    View full-size slide

  16. !16
    JVM CI
    Sulong (LLVM)
    Truffle
    Graal Compiler
    Substrate VM
    Java HotSpot VM

    View full-size slide

  17. Closed-world assumption
    !17
    Dead code elimination
    Substrate
    VM
    Classes
    JDK
    Classes
    JDK
    Classes
    Substrate
    VM
    Classes
    Java
    Application
    Classes
    Java
    Application
    Classes
    Native
    Executable

    View full-size slide

  18. !18
    Not supported
    The Dark Side
    ● Dynamic classloading
    ● InvokeDynamic & Method handles
    ● Finalizer
    ● Security manager
    ● JVMTI, JMX, native VM Interfaces
    OK with caveats in usage
    ● Reflection (manual list)
    ● Dynamic proxy (manual list)
    ● JNI (manual list)
    ● Static initializers
    ● Lambda, Threads (OK, pfff!)
    ● References (similar)

    View full-size slide

  19. !19
    Not supported
    The Dark Side
    ● Dynamic classloading
    ● InvokeDynamic & Method handles
    ● Finalizer
    ● Security manager
    ● JVMTI, JMX, native VM Interfaces
    OK with caveats in usage
    ● Reflection (manual list)
    ● Dynamic proxy (manual list)
    ● JNI (manual list)
    ● Static initializers
    ● References (similar)
    The Good Parts

    View full-size slide

  20. HOW QUARKUS
    WORKS

    View full-size slide

  21. !21
    What does a framework do at startup time
    Move startup time to build time
    ● Parse config files
    ● Classpath & classes scanning
    ○ for annotations, getters or other metadata
    ● Build framework metamodel objects
    ● Prepare reflection and build proxies
    ● Start and open IO, threads etc

    View full-size slide

  22. !22
    Do the work once, not at each start
    All the bootstrap classes are no longer loaded
    Less time to start, less memory used
    Less or no reflection nor dynamic proxy
    Build time benefits

    View full-size slide

  23. !23
    Drives the gathering of metadata needed by GraalVM
    More Build time benefits
    ● based on framework knowledge
    ● Classes using reflection, resources, etc
    Minimize dependencies
    Help dead code elimination

    View full-size slide

  24. !24
    The end result of a Quarkus build
    should be just enough bytecode to
    start the services that your application
    requires
    Anatomy of a Quarkus Application

    View full-size slide

  25. !25
    Traditional Application
    Application Startup
    ● Scan for annotations
    ● Parse descriptors
    ● Generate metamodel
    ● Start Services
    Quarkus
    ● Start Services

    View full-size slide

  26. !26
    The final application contains
    Anatomy of a Quarkus Application
    ● Your (possibly transformed) application code
    ● All libraries needed for runtime
    ● Generated code to wire up and start your services
    ● Generated CDI (ArC) bean classes

    View full-size slide

  27. !27
    Quarkus Extensions
    RESTEasy
    Netty
    Hibernate ORM
    Hibernate Validator
    MP OpenAPI
    MP JWT
    Eclipse Vert.X
    Agroal (conn pool)
    Narayana JTA
    MP Reactive
    Messaging
    Apache Camel
    ...
    Quarkus Core
    Arc (DI)
    Jandex Gizmo Graal SDK
    HotSpot SubstrateVM

    View full-size slide

  28. !28
    Quarkus Consists of Two Parts
    Core Runtime
    Core Deployment
    Undertow Runtime
    Undertow
    Deployment
    ArC Runtime
    ArC Deployment

    View full-size slide

  29. !29
    Build Process
    Compile
    Provision
    (curate)
    Wiring &
    Assemble
    (deployment) AOT Native
    Compilation
    Hotspot Runnable & Image
    Native Executable &
    Image
    app.jar frameworks Runnable java app native-app

    View full-size slide

  30. !30
    Provisioning

    View full-size slide

  31. !31
    Provisioning Phase
    ● Applications only depend on runtime components
    ● But we need the deployment components to execute the build
    ● Provisioning phase resolves the required deployment
    dependencies

    View full-size slide

  32. !32
    Provisioning Phase
    ● Extensions contain a quarkus-extension.properties, generated
    by the extension-maven-plugin
    ● This tells Quarkus what the corresponding deployment artifact is

    View full-size slide

  33. !33
    Deployment

    View full-size slide

  34. !34
    Creating the runnable application
    Augmentation Phase
    ● Processing done by @BuildStep methods
    ● All processors produce and consume BuildItem
    instances
    ● Ordering is based on a dependency graph, a build step is
    executed when all its dependencies are available

    View full-size slide

  35. !35
    BuildItem
    ● All information flows through this process via BuildItem
    instances
    ● Two types, SimpleBuildItem and MultiBuildItem
    ● A @BuildStep method will be run as soon as all the items it
    depends on have been produced
    ● The build is seeded with some initial items (e.g. the current
    application root)
    ● The build asks for some specific outputs (e.g.
    GeneratedClassBuildItem)
    ● Core build items are in io.quarkus.deployment.builditem

    View full-size slide

  36. !36
    Build Graph
    ● The build is a directed graph, it starts with the requested
    outputs, and then figures out which @BuildStep
    methods it needs to call to achieve this and in what order
    ● If your method does not produce anything it needs then it
    is not called

    View full-size slide

  37. !37
    CombinedIndexBuildItem
    Important Items
    ● Holds the Jandex annotation index
    ● Can be used to look at any annotation or type hierarchy

    View full-size slide

  38. !38
    AdditionalBeanBuildItem
    Important Items
    ● Producing this turns a given class into a CDI bean
    ● If you have classes in your runtime module that you want to be
    beans you should produce one of these

    View full-size slide

  39. !39
    Configuration

    View full-size slide

  40. !40
    Declarative Config
    Configuration
    ● Configuration is done via @ConfigRoot objects
    ● All config is under the quarkus.* namespace
    ● All config must have javadoc, which used as the
    documentation in the generated config file

    View full-size slide

  41. !41
    Bytecode
    Recording

    View full-size slide

  42. !42
    Recorders let you invoke on an object
    at deployment time, but the actual
    invocation gets delayed to runtime.
    Bytecode Recording

    View full-size slide

  43. !43
    Serializing logic and data
    Bytecode Recording
    ● Recording allows you to specify what happens at startup time, without knowing
    anything about bytecode
    ● Invocations made on a recorder are written to bytecode and executed at runtime
    ● Primitives, JavaBean style objects and collections can all be passed as arguments
    ● The return values can be passed into other recorders (although cannot be used
    directly)

    View full-size slide

  44. !44
    Return Values
    ● The return value from a recorder cannot be used directly (the object it
    represents has not actually been created yet)
    ● But they can be passed to other recorders methods
    ● We do this by creating proxies, so if the return type cannot be proxied
    wrap it in a RuntimeValue<>
    ● This does not have to be the same recorder, or even the same build step
    ● To pass them between build steps wrap them in a BuildItem

    View full-size slide

  45. !45
    Native
    Image

    View full-size slide

  46. !46
    Quarkus simplifies the process
    Substrate
    ● SubstrateVM has a lot of limitations compared to a normal JVM
    ● Quarkus provides tools to easily work around these limitations
    ● Most of these take the form of build items to explicitly request
    substrate functionality
    ● For a full list see io.quarkus.deployment.builditem.substrate package
    ● Also we support compile time boot

    View full-size slide

  47. !47
    Not supported
    The Dark Side
    ● Dynamic classloading
    ● InvokeDynamic & Method handles
    ● Finalizer
    ● Security manager
    ● JVMTI, JMX, native VM Interfaces
    OK with caveats in usage
    ● Reflection (manual list)
    ● Dynamic proxy (manual list)
    ● JNI (manual list)
    ● Static initializers
    ● Lambda, Threads (OK, pfff!)
    ● References (similar)

    View full-size slide

  48. !48
    ReflectiveClassBuildItem
    Native Build Items
    ● Reflection does not work in native images unless it is explicitly
    enabled
    ● This build item allows you to enable reflection for a given class
    ● Fine grained, so you can choose if you want methods, fields and
    constructors registered

    View full-size slide

  49. !49
    ReflectiveHierarchyBuildItem
    Native Build Items
    ● Registers everything about the class for reflection
    ● Supertypes, Field types, method parameters etc
    ● Good for serialization use cases, where you need to set everything
    via reflection

    View full-size slide

  50. !50
    SubstrateResourceBuildItem
    Native Build Items
    ● Resources are not included by default in SubstrateVM
    ● Using this build item you can specify resources that you want to
    include in the image

    View full-size slide

  51. !51
    Boot once, run everywhere
    Compile time boot
    ● When SubstrateVM creates a native image it can run java static initializers as
    part of the process
    ● These run in a normal JVM, with no restrictions
    ● The results are serialized directly into the native image
    ● If you record code with @Record(ExecutionTime.STATIC_INIT) then this code will
    be run once at native image build time
    ● The results are directly unpacked into memory when the native image is actually
    run

    View full-size slide

  52. !53
    Unit and Integration Tests
    Extension Testing Framework
    ● @QuarkusUnitTest can be used to test a different application for
    each test class
    ● Quarkus is started and stopped between each class
    ● @QuarkusTest can also be used (especially for native image), but
    needs its own ‘integration-tests’ module
    ● A comprehensive test suite will generally have both

    View full-size slide

  53. !54
    Thank you.

    View full-size slide