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

Quarkus: Supersonic, Subatomic Java - Openshift...

Quarkus: Supersonic, Subatomic Java - Openshift Days - Day 2

Quarkus: Supersonic, Subatomic Java - Openshift Days - Day 2

Kubernetes بالعربي

February 17, 2021
Tweet

More Decks by Kubernetes بالعربي

Other Decks in Technology

Transcript

  1. Is Java dying!? 2 Q3 plot for 2020 Simply No,

    and more important, A lot of efforts have been put together to make Java more Cloud native • Smaller footprint (Memory and CPU) • Faster Startup • Optimized for short-lived processes • Imperative and Reactive • Supporting cloud dev models (Serverless and Microservices) • Kubernetes native • Fat Jars and Native Executable
  2. 3 But, Java is slow? Multi-step runtime process Multi Step

    runtime process Due to the multi-step execution process described above, a java program is independent of the target operating system. However, because of the same, the execution time is way more than a similar program written in a compiled platform-dependent program ClassLoader loads the main class and all dependencies. Remember Dependency resolution happens at the byte code level
  3. 4 What you might not know! Dependency Injection Java developers

    heavily rely on DI applying patterns like dynamic proxies and IoC. What does this mean? Developers declaratively specify what should happen and the implementation makes sure it does. - Dependency resolution happens at runtime that results in heavy lifting and long start up time. - Is there a chance that dependency resolution fails? Yes, what is the impact? Application will not start “very famous class not found exception” - JEE have CDI specs - Context and dependency injection - and Weld provides the reference implementation and It is integrated in most Application servers if not all. Weld • All beans are discovered at startup • Proxies are dynamically generated • Extensive use of reflection • Expensive to start http://cdi-spec.org/ http://weld.cdi-spec.org/
  4. 5 RSS (Resident Set Size memory) = actual RAM used

    by a process without SWAP Java Heap Metaspace Direct Code Internal • Startup overhead ◦ # of classes, bytecode, JIT • Memory overhead ◦ # of classes, metadata, compilation The hidden truth about Java Classes are indexed, Metadata about annotation is created, injections and dependency resolution happens. This all is waste of memory and time.
  5. 6 Experts did a great job addressing Java performance. But

    no matter what experts do, Java is still slow :)
  6. Quarkus is a K8 native java stack. Subatomic because It

    is very small and lightweight Supersonic because it is fast with unbeatable ignition time Supported on OpenJDK and GraalVM 8 QUARK: elementary particle (subatomic) / US: hardest thing in computer science Whats is Quarkus?
  7. 9 Quarkus Architecture 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 Read Metadata and resolve annotation Generate bytecode Native code generation Dependency Injection Security Integration Automation ...
  8. Ahead-of-time techniques vs Just-in-time During the build, some work like

    annotation scanning, XML parsing, resolving dependencies, declares which classes need reflection at runtime and generates static proxies to avoid reflection, and more is pre-computed. Quarkus can also use GraalVM to generate native executables using native-image. This has two direct benefits: faster startup time and lower memory consumption. 10 How does It work? Augmentation Augmentation Jandex Parse any descriptors and read annotations, but should not attempt to load any application classes Gizmo Generating bytecode Where is the value? OOOK! Take This Scenario While XML parsers are required to parse descriptors and configuration files in other frameworks, in Quarkus The only reason that a Quarkus application should load an XML parser is if the user is using XML in their application. Any XML parsing of configuration should be done in the Augmentation phase.
  9. Quarkus aims to do as much work as possible at

    build time, to keep the resulting application as small and fast as possible Runtime should only contain classes that are needed to actually run the application. 11 Quarkus Core Philosophy Fast Ignition Min footprint
  10. 12 CDI - The foundation • Context Dependency Injection -

    CDI ◦ Injecting bean into another ◦ Injecting configuration ◦ Injecting resources to a component • CDI is built on the concept of "loose coupling, strong typing", meaning that beans are loosely coupled, but in a strongly-typed way. • CDI is built on the concept of "loose coupling, strong typing", meaning that beans are loosely coupled, but in a strongly-typed way. • CDI is also bringing interceptors, decorators and events to DI. • Quarkus is based on a CDI implementation called ArC • ArC doesn’t fully implement CDI, only most commonly used subset of the specification is implemented.
  11. 13 ArC - The magic • ArC is a build-time

    oriented dependency injection based on CDI 2.0 • Beans and proxies generated at build time • Removing Unused Beans (In standard CDI, all beans are retained by the container no matter whether they’re needed or not) • Minimal reflection (private members only) • Startup is very fast ArC plus integration runtime consist of 72 classes and occupies ~ 140 KB in jars. Weld 3.1.1 (CDI Reference Implementation) core is roughly 1200 classes and approx. 2 MB jar. In other words, ArC runtime takes approx. 7% of the Weld runtime in terms of number of classes and jar footprint. ArC Supported features https://quarkus.io/guides/cdi-reference#supported_features
  12. Application jar 14 Quarkus Packaging • Application code only Jar

    • Executable (Runnable) Jar ◦ It is an executable JAR, not an Uber-JAR ◦ Quarkus copies all the dependencies into the target/lib directory ◦ Jar MANIFEST.MF contains Class-Path pointing to all jars under target/lib directory ◦ Jar MANIFEST.MF contains Main-Class: io.quarkus.runner.GeneratedMain ClassA.java ClassB.java application.properties ClassA.class ClassB.class application.properties Application runnable jar ClassA.class ClassB.class application.properties Class-Path MANIFEST.MF Main-Class
  13. Package your app (Rest + CRUD) $ mvn clean package

    → app-1.0.0-SNAPSHOT.jar (~12 KB) → app-1.0.0-SNAPSHOT-runner.jar (~406 KB) → lib folder (~19 MB) Run your app $ java -jar target/physicians-1.0.0-SNAPSHOT-runner.jar 15 Quarkus Packaging MANIFEST.MF adds lib folder to classpath
  14. Go Native! Native Image Rest + JPA CRUD (Native) ~

    36 milliseconds 16 Quarkus Native Executable Rest + JPA CRUD ~ 1 second startup time, is this enough!
  15. Quarkus on GraalVM 17 Native Image It is a technology

    to ahead-of-time compile Java code to a standalone executable, called a native image. This executable includes the application classes, classes from its dependencies, runtime library classes, and statically linked native code from JDK. It does not run on the Java VM. Install GraalVM native-image builder tool for your OS $ {GRAALVM_HOME}/bin/gu install native-image Build your binary executable (native image) using maven Quarkus plugin $ mvn package -Pnative Run your Executable
  16. 18 Kubernetes When bootstrapping Quarkus application, Two Docker files are

    generated • Dockerfile.jvm: To containerize the application using the generated JAR • Dockerfile.native: To containerize the application using the native executable For Openshift deployment Use the magic of S2I $ mvn clean package -Dquarkus.kubernetes.deploy=true Add -Dquarkus.kubernetes-client.trust-certs=true to accept self-signed certs Isn’t it easy!!! But What is happening? Deploy on Openshift
  17. 19 Push image $ mvn clean package -Dquarkus.container-image.push=true Push image

    and deploy the app $mvn clean package -Dquarkus.kubernetes.deploy=true Deploy on Openshift
  18. 20 Receiving source from STDIN as archive ... Caching blobs

    under "/var/cache/blobs". Getting image source signatures Copying blob sha256:bade03519b0d36b16221d683ad4b69fe6e3ab13bce6558c4a33e4c844680d700 ... Writing manifest to image destination Storing signatures Generating dockerfile with builder image registry.access.redhat.com/openjdk/openjdk-11-rhel7@sha256:c343983d08baf2b3cc19483734808b07523a0860a5b17fdcb32de2d1b85306ca STEP 1: FROM registry.access.redhat.com/openjdk/openjdk-11-rhel7@sha256:c343983d08baf2b3cc19483734808b07523a0860a5b17fdcb32de2d1b85306ca STEP 2: LABEL "io.openshift.s2i.destination"="/tmp" "io.openshift.build.image"="registry.access.redhat.com/openjdk/openjdk-11-rhel7@sha256:c343983d08baf2b3cc19483734808b07523a0860a5b17fdcb32de2d1b85306ca" "io.openshift.build.source-location"="/tmp/build/inputs" STEP 3: ENV OPENSHIFT_BUILD_NAME="physicians-1" OPENSHIFT_BUILD_NAMESPACE="quarkus" STEP 4: USER root STEP 5: COPY upload/src /tmp/src STEP 6: RUN chown -R 185:0 /tmp/src STEP 7: USER 185 STEP 8: RUN /usr/local/s2i/assemble INFO S2I source build with plain binaries detected INFO Copying binaries from /tmp/src to /deployments ... physicians-1.0.0-SNAPSHOT-runner.jar lib/ lib/com.fasterxml.jackson.core.jackson-annotations-2.10.4.jar .... lib/org.yaml.snakeyaml-1.26.jar STEP 9: CMD /usr/local/s2i/run STEP 10: COMMIT temp.builder.openshift.io/quarkus/physicians-1:aec0a8ae Getting image source signatures Copying blob sha256:f91d01e7b88f8f9e151243e35e2b2af90dda72fc326330bfd5cb67e2c8491cf8 ... Writing manifest to image destination Storing signatures Pushing image image-registry.openshift-image-registry.svc:5000/quarkus/physicians:1.0.0-SNAPSHOT ... Getting image source signatures Copying blob sha256:8ef598dbb46127ae7fd03bd1004f2e64e451a84213a72165166cbfb5e6f515b8 ... Writing manifest to image destination Storing signatures Successfully pushed image-registry.openshift-image-registry.svc:5000/quarkus/physicians@sha256:567a8ee5977338b50d6ff38126db5a89edec0486ca407a0b7e5b0ae9e8fe9523 Push successful
  19. S2I - SOURCE TO IMAGE 21 Build From Source Build

    From Binary Build From Image Multi Stage Build Still not enough, You can go for S2I Custom Build
  20. Quarkus supports the notion of configuration profiles. This allows you

    to have multiple configurations in the same file and to select them via a profile name. By default, Quarkus has three profiles, although it is possible to create your own and use as many as you like. The built-in profiles are: • dev: Activated when in development mode (when running mvn quarkus:dev). • test: Activated when running tests. • prod: The default profile when not running in development or test mode. The syntax is %{profile}.config.key=value in the application.properties file. For example %dev.quarkus.mongodb.connection-string = mongodb://localhost:27017/persons If profile is omitted, then the property works for all Then, you set the system variable depending on your needs: • Use mvn -Dquarkus.profile=staging quarkus:dev if you are developing, • Or java -Dquarkus.profile=staging -jar profiles-1.0-runner.jar if you are running your executable JAR. 22 Profiles Some Quarkus Profile Configuration Properties
  21. { Your code } Application Environment with Red Hat 23

    “Quarkus powers the next-generation Red Hat stack for hybrid-cloud applications” Quarkus Camel-K Kogito
  22. 24 Kogito • Encapsulate your business processes/rules into your microservices

    • Fit into Knative serverless • Superfast boot time, low footprint (GraalVM native image) • Operator-driven service lifecycle management • Leveraging / integrating many other (cloud) technologies • Variety of developer tools • GUI Process designer • Swagger docs VSCode
  23. 26 Quarkus in action Quarkus based “Medical Second Opinion” Portal

    solution with following components 1. Physicians: physician profile service connecting to Mongodb 2. Cases: case request service connecting to Postgresql 3. bp: kogito based business process service 4. Composite: a simple composite service using proxy and microgateway design patterns 5. UI: AngularJS
  24. 30