Quarkus Workshops: IT training & practical know-how from experts
Java was developed as the first platform-independent language and it did set new standards: with the JVM, as preferred platform for Android development or with standards like Java EE. Modern technologies like cloud computing, microservices und containerization though present Java with new challenges.
Because the Java language originally had been designed for server-based computer programs and therefor was not optimized for the cloud. This becomes apparent in comparisons with other languages like Node.js or Go.
If you're familiar with Java and want to make your code cloud-ready with Quarkus, our training sessions will equip you and your team with the necessary expertise to successfully implement Quarkus applications.
Christoph Ehlers
Head of Custom IT Solutions
Quarkus is a cloud-native Red Hat stack for for developing web applications, based on Jakarta EE and MicroProfile standards. Compared with an application developed using common competitor products, a Quarkus application provides a much shorter start time and significantly lower memory requirements, a great advantage especially in serverless computing environments.
Quarkus also pursues the "container first" approach. These qualities make Quarkus an excellent choice for use in cloud and container environments.
| Classic Java Webframe Works or Application Server | Quarkus |
|---|---|
| memory demanding | minimal memory requirements |
| long start time | very short start time |
| not well suited for serverless computing | excellent for serverless computingexzellent |
| needs JVM | natively compilable with GraalVM |
| Σ does not support use in cloud, partially impedes use | Σ ideal for use in the cloud |
More than
200 customers
trust ConSol for their IT & software
Quarkus Improves your Business
If Java code meets certain requirements, it can be compiled into a native application via GraalVM. This way the native application is starting up to 30 times faster, the application’s memory requirements drops to about a tenth of the traditional cloud-native stack.
If a native compilation is wanted, not every library can be integrated into a Quarkus application. Yet Quarkus provides a rich ecosystem of libraries supporting native compilation – maintained by Red Hat as well as by the community. This includes libraries like undertow, RESTEasy and Hibernate ORM. There are also Quarkus specific features that simplify the developing of and with Quarkus applications like:
- Integration with Maven and Gradle
- Command-Line-Tooling for Management Quarkus specific dependencies
- Targets for creating a native application
- Powerful development mode for quick feedback during development
- Testing with JUnit5 and Rest Assured
- Testing of native applications
Interested? Discover the future of cloud native Java applications - today!
Quarkus Workshops: From Testing to Productive Deployment
Trial Course, Deep Dive & Support During the First Days of Development
While some libraries and features are standardized or their use is known from other stacks, other libraries are Quarkus-specific. They also have to be correctly integrated into the application. In order to enable you and your team to do that and to train you for the development of Quarkus applications as well as for productive use, we offer the following workshops:
1 Day: Quarkus Basic Features at a Glance
- Setting up a small REST application from scratch
- Configuring the application with regard to cloud native deployments
- Linking a persistence layer in the form of a relational database
- User authentication via JWT tokens, including the basic configuration of a Keycloak server
- Native compiling of the application
- Developing Unit Tests
- Containerizing the application
3 Days: In-depth knowledge of individual Quarkus segments
- Setting up a multi module project with Maven
- Creating an own docker image
- Health & readiness checks, implementing custom checks
- MicroProfile Metrics
- @Counted, @Timed, @Gauge, @Metered
- Histogramme
- MicroProfile Fault Tolerance
- @Retry, @Timeout, @Fallback
- Circuit Breaker
- Consuming REST-APIs with MicroProfile REST client
- MicroProfile OpenTracing
- Integrating Jaeger
- Configuring request independent spans
- Hibernate and Panache: differences, common features
- Integrating messaging systems (JMS & Kafka)
- Integrating Apache Camel Mutiny for reactive programming
We support you and your team during the first five days of development. We coach you and are available for questions and bug fixes, this way you achieve the best possible results with Quarkus.
Tip: Basically, the levels build on each other but can also be booked separately, depending on the level of knowledge in your company.
Important Quarkus & Java terms
What is Jakarta EE?
Jakarta EE is an open standard of the Eclipse Foundation and successor of Java EE 8. The standard defines APIs for features and the corresponding performance. The defined features include dependency injection (CDI, JSR 365), definition of RESTful web services (JAX-RS, JSR 370), mapping Java objects on relational databases (JSR 221, JSR 222, JSR 367 and JSR 338).
Implementation will be in the libraries and application servers respectively, which implement the standard: like Tomcat, Glassfish, Payara and Quarkus.
What is MicroProfile?
The MicroProfile standard builds on Jakarta EE. Like Jakarta EE MicroProfile is open source as well and is developed by the Eclipse Foundation. The features aim at the implementation of microservices. You can find APIs for defining REST Clients, monitoring the application, reading technical and functional statistics and for configuring the application.
As with Jakarta EE, implementation with MicroProfile takes place in the libraries or application servers implementing the standard.
What is GraalVM?
GraalVM is a JVM developed by Oracle, based on Java 8 and Java 11. GraalVM is offered free and open source (GraalVM CE) and in a commercial version, including support and other runtime optimizations (GraalVM EE). GraalVM CE may be used for productive purposes.
Besides aiming to optimize the runtime of Java programs, GraalVM offers the opportunity to translate Java programs into natively executable binary files. This feature is generally known as "Ahead-of-Time (AoT) compilation". In the GraalVM eco system this feature is called "native-image". The primary goal of natively compiled Java programs is not optimizing the runtime but optimizing processor and storage utilization.
Why cloud native? And what makes applications cloud native?
Automation
Hardware is unreliable, software is complex. Hardware components fail, applications need to be restarted. Both situations require manual intervention, the process is time-consuming and cost-intensive. When using a containerized infrastructure like via Kubernetes, many processes can be automated. If, for example, hardware is failing, the containers affected by the failure are restarted automatically on hardware not affected.
Containerization also provides the possibility of horizontal scaling: is the load to high on one application, it is instantiated several times and the load is distributed on all of the applications instances. If the load decreases, the instances not needed any longer will be stopped. This can be automated via metrics, provided by the containerized application via its status. The trend here is automation, one of the fundamental pillars of site reliability engineering.
Cloud native criteria
For the application, running in such an environment has some implications, both technical and functional in nature. On the one hand, for optimal use of automation, a tailored approach to the environment is necessary, for example, using the provided metrics. On the other hand, the application should be capable of being instantiated multiple times. For web applications with login functionality over sessions, this means that the state of the session cannot be held in the application. An application that meets these criteria is considered cloud-native.
What is a microservice?
The definition of a Microservices is difficult to describe via lines of code or similar metrics, which might make the term misleading. It can be better described via functionality: A microservice is responsible for a functional domain, whereby domains create natural transaction boundaries. All data requiring strong consistency among each other form a domain. As such, microservices can be regarded a form of the single responsibility principle from software engineering, thought a step further.
+49-89-45841-100Any Questions about Quarkus Workshops?
Let's talk!
Judith Bato