#why use quarkus kubernetes | Explore Tumblr posts and blogs

itbeatsbookmarks · 5 years ago

Link

(Via: Hacker News)

Today’s developers are expected to develop resilient and scalable distributed systems. Systems that are easy to patch in the face of security concerns and easy to do low-risk incremental upgrades. Systems that benefit from software reuse and innovation of the open source model. Achieving all of this for different languages, using a variety of application frameworks with embedded libraries is not possible.

Recently I’ve blogged about “Multi-Runtime Microservices Architecture” where I have explored the needs of distributed systems such as lifecycle management, advanced networking, resource binding, state abstraction and how these abstractions have been changing over the years. I also spoke about “The Evolution of Distributed Systems on Kubernetes” covering how Kubernetes Operators and the sidecar model are acting as the primary innovation mechanisms for delivering the same distributed system primitives.

On both occasions, the main takeaway is the prediction that the progression of software application architectures on Kubernetes moves towards the sidecar model managed by operators. Sidecars and operators could become a mainstream software distribution and consumption model and in some cases even replace software libraries and frameworks as we are used to.

The sidecar model allows the composition of applications written in different languages to deliver joint value, faster and without the runtime coupling. Let’s see a few concrete examples of sidecars and operators, and then we will explore how this new software composition paradigm could impact us.

Out-of-Process Smarts on the Rise

In Kubernetes, a sidecar is one of the core design patterns achieved easily by organizing multiple containers in a single Pod. The Pod construct ensures that the containers are always placed on the same node and can cooperate by interacting over networking, file system or other IPC methods. And operators allow the automation, management and integration of the sidecars with the rest of the platform. The sidecars represent a language-agnostic, scalable data plane offering distributed primitives to custom applications. And the operators represent their centralized management and control plane.

Let’s look at a few popular manifestations of the sidecar model.

Envoy

Service Meshes such as Istio, Consul, and others are using transparent service proxies such as Envoy for delivering enhanced networking capabilities for distributed systems. Envoy can improve security, it enables advanced traffic management, improves resilience, adds deep monitoring and tracing features. Not only that, it understands more and more Layer 7 protocols such as Redis, MongoDB, MySQL and most recently Kafka. It also added response caching capabilities and even WebAssembly support that will enable all kinds of custom plugins. Envoy is an example of how a transparent service proxy adds advanced networking capabilities to a distributed system without including them into the runtime of the distributed application components.

Skupper

In addition to the typical service mesh, there are also projects, such as Skupper, that ship application networking capabilities through an external agent. Skupper solves multicluster Kubernetes communication challenges through a Layer 7 virtual network and offers advanced routing and connectivity capabilities. But rather than embedding Skupper into the business service runtime, it runs an instance per Kubernetes namespace which acts as a shared sidecar.

Cloudstate

Cloudstate is another example of the sidecar model, but this time for providing stateful abstractions for the serverless development model. It offers stateful primitives over GRPC for EventSourcing, CQRS, Pub/Sub, Key/Value stores and other use cases. Again, it an example of sidecars and operators in action but this time for the serverless programming model.

Dapr

Dapr is a relatively young project started by Microsoft, and it is also using the sidecar model for providing developer-focused distributed system primitives. Dapr offers abstractions for state management, service invocation and fault handling, resource bindings, pub/sub, distributed tracing and others. Even though there is some overlap in the capabilities provided by Dapr and Service Mesh, both are very different in nature. Envoy with Istio is injected and runs transparently from the service and represents an operational tool. Dapr, on the other hand, has to be called explicitly from the application runtime over HTTP or gRPC and it is an explicit sidecar targeted for developers. It is a library for distributed primitives that is distributed and consumed as a sidecar, a model that may become very attractive for developers consuming distributed capabilities.

Camel K

Apache Camel is a mature integration library that rediscovers itself on Kubernetes. Its subproject Camel K uses heavily the operator model to improve the developer experience and integrate deeply with the Kubernetes platform. While Camel K does not rely on a sidecar, through its CLI and operator it is able to reuse the same application container and execute any local code modification in a remote Kubernetes cluster in less than a second. This is another example of developer-targeted software consumption through the operator model.

More to Come

And these are only some of the pioneer projects exploring various approaches through sidecars and operators. There is more work being done to reduce the networking overhead introduced by container-based distributed architectures such as the data plane development kit (DPDK), which is a userspace application that bypasses the layers of the Linux kernel networking stack and access directly to the network hardware. There is work in the Kubernetes project to create sidecar containers with more granular lifecycle guarantees. There are new Java projects based on GraalVM implementation such as Quarkus that reduce the resource consumption and application startup time which makes more workloads attractive for sidecars. All of these innovations will make the side-car model more attractive and enable the creation of even more such projects.

Sidecars providing distributed systems primitives

I’d not be surprised to see projects coming up around more specific use cases such as stateful orchestration of long-running processes such as Business Process Model and Notation (BPMN) engines in sidecars. Job schedulers in sidecars. Stateless integration engines i.e. Enterprise Integration Patterns implementations in sidecars. Data abstractions and data federation engines in sidecars. OAuth2/OpenID proxy in sidecars. Scalable database connection pools for serverless workloads in sidecars. Application networks as sidecars, etc. But why would software vendors and developers switch to this model? Let’s see a few of the benefits it provides.

Runtimes with Control Planes over Libraries

If you are a software vendor today, probably you have already considered offering your software to potential users as an API or a SaaS-based solution. This is the fastest software consumption model and a no-brainer to offer, when possible. Depending on the nature of the software you may be also distributing your software as a library or a runtime framework. Maybe it is time to consider if it can be offered as a container with an operator too. This mechanism of distributing software and the resulting architecture has some very unique benefits that the library mechanism cannot offer.

Supporting Polyglot Consumers

By offering libraries to be consumable through open protocols and standards, you open them up for all programming languages. A library that runs as a sidecar and consumable over HTTP, using a text format such as JSON does not require any specific client runtime library. Even when gRPC and Protobuf are used for low-latency and high-performance interactions, it is still easier to generate such clients than including third party custom libraries in the application runtime and implement certain interfaces.

Application Architecture Agnostic

The explicit sidecar architecture (as opposed to the transparent one) is a way of software capability consumption as a separate runtime behind a developer-focused API. It is an orthogonal feature that can be added to any application whether that is monolithic, microservices, functions-based, actor-based or anything in between. It can sit next to a monolith in a less dynamic environment, or next to every microservice in a dynamic cloud-based environment. It is trivial to create sidecars on Kubernetes, and doable on many other software orchestration platforms too.

Tolerant to Release Impedance Mismatch

Business logic is always custom and developed in house. Distributed system primitives are well-known commodity features, and consumed off-the-shelf as either platform features or runtime libraries. You might be consuming software for state abstractions, messaging clients, networking resiliency and monitoring libraries, etc. from third-party open source projects or companies. And these third party entities have their release cycles, critical fixes, CVE patches that impact your software release cycles too. When third party libraries are consumed as a separate runtime (sidecar), the upgrade process is simpler as it is behind an API and it is not coupled with your application runtime. The release impedance mismatch between your team and the consumed 3rd party libraries vendors becomes easier to manage.

Control Plane Included Mentality

When a feature is consumed as a library, it is included in your application runtime and it becomes your responsibility to understand how it works, how to configure, monitor, tune and upgrade. That is because the language runtimes (such as the JVM) and the runtime frameworks (such as Spring Boot or application servers) dictate how a third-party library can be included, configured, monitored and upgraded. When a software capability is consumed as a separate runtime (such as a sidecar or standalone container) it comes with its own control plane in the form of a Kubernetes operator.

That has a lot of benefits as the control plane understands the software it manages (the operand) and comes with all the necessary management intelligence that otherwise would be distributed as documentation and best practices. What’s more, operators also integrate deeply with Kubernetes and offer a unique blend of platform integration and operand management intelligence out-of-the-box. Operators are created by the same developers who are creating the operands, they understand the internals of the containerized features and know how to operate the best. Operators are executables SREs in containers, and the number of operators and their capabilities are increasing steadily with more operators and marketplaces coming up.

Software Distribution and Consumption in the Future

Software Distributed as Sidecars with Control Planes

Let’s say you are a software provider of a Java framework. You may distribute it as an archive or a Maven artifact. Maybe you have gone a step further and you distribute a container image. In either case, in today’s cloud-native world, that is not good enough. The users still have to know how to patch and upgrade a running application with zero downtime. They have to know what to backup and restore its state. They have to know how to configure their monitoring and alerting thresholds. They have to know how to detect and recover from complex failures. They have to know how to tune an application based on the current load profile.

In all of these and similar scenarios, intelligent control planes in the form of Kubernetes operators are the answer. An operator encapsulates platform and domain knowledge of an application in a declaratively configured component to manage the workload.

Sidecars and operators could become a mainstream software distribution and consumption model and in some cases even replace software libraries and frameworks as we are used to.

Let’s assume that you are providing a software library that is included in the consumer applications as a dependency. Maybe it is the client-side library of the backend framework described above. If it is in Java, for example, you may have certified it to run it on a JEE server, provided Spring Boot Starters, Builders, Factories, and other implementations that are all hidden behind a clean Java interface. You may have even backported it to .Net too.

With Kubernetes operators and sidecars all of that is hidden from the consumer. The factory classes are replaced by the operator, and the only configuration interface is a YAML file for the custom resource. The operator is then responsible for configuring the software and the platform so that users can consume it as an explicit sidecar, or a transparent proxy. In all cases, your application is available for consumption over remote API and fully integrated with the platform features and even other dependent operators. Let’s see how that happens.

Software Consumed over Remote APIs Rather than Embedded Libraries

One way to think about sidecars is similar to the composition over inheritance principle in OOP, but in a polyglot context. It is a different way of organizing the application responsibilities by composing capabilities from different processes rather than including them into a single application runtime as dependencies. When you consume software as a library, you instantiate a class, call its methods by passing some value objects. When you consume it as an out-of-process capability, you access a local process. In this model, methods are replaced with APIs, in-process methods invocation with HTTP or gRPC invocations, and value objects with something like CloudEvents. This is a change from application servers to Kubernetes as the distributed runtime. A change from language-specific interfaces, to remote APIs. From in-memory calls to HTTP, from value objects to CloudEvents, etc.

This requires software providers to distribute containers and controllers to operate them. To create IDEs that are capable of building and debugging multiple runtime services locally. CLIs for quickly deploying code changes into Kubernetes and configuring the control planes. Compilers that can decide what to compile in a custom application runtime, what capabilities to consume from a sidecar and what from the orchestration platform.

Software consumers and providers ecosystem

In the longer term, this will lead to the consolidation of standardized APIs that are used for the consumption of common primitives in sidecars. Rather than language-specific standards and APIs we will have polyglot APIs. For example, rather than Java Database Connectivity (JDBC) API, caching API for Java (JCache), Java Persistence API (JPA), we will have polyglot APIs over HTTP using something like CloudEvents. Sidecar centric APIs for messaging, caching, reliable networking, cron jobs and timer scheduling, resource bindings (connectors to other APIs, protocols), idempotency, SAGAs, etc. And all of these capabilities will be delivered with the management layer included in the form of operators and even wrapped with self-service UIs. The operators are key enablers here as they will make this even more distributed architecture easy to manage and self-operate on Kubernetes. The management interface of the operator is defined by the CustomResourceDefinition and represents another public-facing API that remains application-specific.

This is a big shift in mentality to a different way of distributing and consuming software, driven by the speed of delivery and operability. It is a shift from a single runtime to multi runtime application architectures. It is a shift similar to what the hardware industry had to go through from single-core to multicore platforms when Moore’s law ended. It is a shift that is slowly happening by building all the elements of the puzzle: we have uniformly adopted and standardized containers, we have a de facto standard for orchestration through Kubernetes, possibly improved sidecars coming soon, rapid operators adoption, CloudEvents as a widely agreed standard, light runtimes such as Quarkus, etc. With the foundation in place, applications, productivity tools, practices, standardized APIs, and ecosystem will come too.

This post was originally published at The New Stack here.

#IFTTT #Feedly

0 notes

holytheoristtastemaker · 5 years ago

Link

The 12 Factor App approach is for defining a clean contract between the application and running environment. The application and running environment can focus on their own domain and will not step into each others’ toes.

You might have heard of the 12 Factor App application development methodology, published by Heroku, and specifically designed to create applications that will serve as the foundation for a Software-as-a-Service offering.

In this article, we will walk you through the 12 Factor App approach.

Why the 12 Factor App?

The 12 Factor App approach for defining a clean contract between the application and running environment. The application and running environment can focus on their own domain and will not step into each others’ toes.

What is the 12 Factor App?

12 Factor App is a methodology, best practices, and manifesto that says apps should:

Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;

Have a clean contract with the underlying operating system, offering maximum portability between execution environments;

Be suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;

Minimize divergence between development and production, enabling continuous deployment for maximum agility;

And can scale up without significant changes to tooling, architecture, or development practices.

The 12 Factor App has 12 factors.

How to create a 12 Factor App

For the purposes of this article I will examine how to create a 12 Factor App using Eclipse MicroProfile and Kubernetes. Eclipse MicroProfile is an open source project and community, established by the Eclipse Foundation in 2016 and includes members such as IBM, Red Hat, Tomitribe, Payara, LJC, and many others. It adopts lightweight, iterative processes and has a rapid release cycle.

It has 3 releases per year. In February 2010, MicroProfile released MicroProfile 3.3 including:

MicroProfile Config 1.4

MicroProfile Fault Tolerance 2.1

MicroProfile Health 2.2

MicroProfile JWT Authentication 1.1

MicroProfile Metrics 2.3

MicroProfile OpenAPI 1.1

MicroProfile OpenTracing 1.3

MicroProfile Rest Client 1.4

CDI 2.0

Common Annotations 1.3

JAX-RS 2.1

JSON-B 1.0

JSON-P 1.1

Eclipse MicroProfile has about a dozen implementations with various levels of support: Open Liberty, Quarkus, Payara, TomEE, Wildfly, KumuluzEE, Piranha, Apache Launcher, and others.

In this session, I will show you how to use some Eclipse MicroProfile Specs to fulfill the 12 Factor App. Let’s take a look at the 12 Factors one by one and focus on the how aspect.

1. Codebase

You can use GitHub repositories to provide a dedicated codebase per microservice so that each microservice can have its own release schedule. It is important that the codebase is version controlled.

Following the discipline of a single repository for an application forces the teams to analyze the seams of their application, and identify potential monoliths that should be split off into microservices.

2. Dependencies

Instead of packaging the third-party libraries inside your microservice, specify your dependencies in your Maven pom.xml or Gradle settings.gradle file. This enables you to freely move up to newer versions.

3. Config

Configuration is one of the most important factors. The golden rule of developing microservices is to write once, configure everywhere. When changing configuration, you don’t want to repackage your microservices. The way to achieve this is to externalise the configuration from the microservice application code. MicroProfile Config enables you to place configuration in properties files that can be easily updated without recompiling your microservices.

You can then use MicroProfile Config to access configuration “my.string.property” via

Programmatically lookup

Config config =ConfigProvider.getConfig(); config.getValue(“my.string.property”, String.class);

Via CDI Injection@Inject @ConfigProperty(name=”my.string.property”) String myPropV;

The property ”my.string.property” can be stored in System Properties, Environment Variables, or other config sources such as Kubernetes Config Map, etc. In this way, you can update the property without the need to repack the 12 Factor App.

4. Backing services

They should be configurable so that you can easily switch the attached resource by just changing the configuration. Again, MicroProfile Config and MicroProfile Rest Client can help here. MicroProfile Rest Client enables the client to treat backing services as attached resources via the following mechanism:

Specify the interface of the backing services and annotate with @RegisterRestClient

Package com.acme; @Dependent @RegisterRestClient @RegisterProvider(UnknownUrlExceptionMapper.class) @Path("/properties") public interface SystemClient { @GET @Produces(MediaType.APPLICATION_JSON) public Properties getProperties() throws UnknownUrlException, ProcessingException; }

Inject the backing service interface in the client

@Inject @RestClient private SystemClient defaultRestClient;

Bind the backing service via config property

com.acme.SystemClient/mp-rest/url=http://localhost:9080/system

In this case, if you want to swap the attaching resources simply via updating the value of the binding property as long as the services implement the same interface.

5. Build, release, run

The build stage produces an image with the source code. If you use maven, your build stage is when you issue the maven build command, e.g. mvn package.

The Release stage takes the image from the build and package with the config. If you use Docker, the command ”docker build” maps to the release stage, which then pushes the docker image to Docker hub to get ready to move towards the run stage.

The run stage is to execute the image in the execution environment. You can take “docker run” or when you deploy images to Kubernetes when issuing “kubectl apply -f deployment.yaml”.

6. Processes

Microservices should be stateless. REST is a well-adopted transport protocol, and JAX-RS, included in MicroProfile, can be used to achieve a RESTful architecture. Systems that follow the REST paradigm are stateless. In this way, underlying infrastructure can destroy or create new microservices without losing any information.

When using JAX-RS, you will need to define a subclass of Application and JAX-RS resources.

@ApplicationPath("System") public class SystemApplication extends Application {} @Path("properties") public class PropertiesResource { @GET @Produces(MediaType.APPLICATION_JSON) public JsonObject getProperties() {…} }

With the above 2 classes, the endpoint of http://host:port/System/properties will be exposed as a RESTful service.

7. Port binding

Export services using port binding. In the world of microservices, it is common that microservices talk to each other. When deploying them in the cloud, the ports need to change, so it is important to have a way to rebind the port.

MicroProfile Config can help this. You can specify the new port in Kubernetes ConfigMap, and MicroProfile Config automatically picks up the value to give the correct info to the deployed microservices. MicroProfile Rest Client can help with creating client code to connect from one microservice to another.

Refer to 4. Backing Services for the details of MicroProfile Rest Client. Once using MicroProfile, in a different environment, you can specify the backend binding service via the property of ${fully.qualified.interface.name}/mp-rest/url=http://localhost:9080/system

You can use MicroProfile config to specify the property value. If you specify the above property as an environment, you can swap any non-numeric-alpha with _ because of the restriction rules for naming environment variables. For instance, the property name com.acme.SystemClient/mp-rest/url will be com_acme_SystemClient_mp_rest_url.

8. Concurrency

The microservices should be able to be scaled up or down, depending on the workload. Knative autoscaling can help with this.

9. Disposability

Microservices should start up and shut down very fast in order to save costs and improve efficiency. The microservices should be resilient.

MicroProfile Fault Tolerance can help out with this. MicroProfile Fault Tolerance provides the following annotations to make your microservices resilient.

@Retry - recover from a brief network glitch @Timeout - specify a time out in order to prevent from waiting for a long period of time @CircuitBreaker - prevent from a repeatable errors @Bulkhead - prevent faults in one part of the system from cascading to the entire system @Fallback - provide a backup plan

The following example demonstrates the Get operation onClientSide is very resilient. It will respond to its caller within 100 ms, no matter how slow the backend service is. If there is an exception, the fallback operation will be executed.

@Path("/client") @ApplicationScoped public class ClientController { @Inject @RestClient private Service service; @Inject @ConfigProperty(name="conference") String conf; @GET @Path("/test/{parameter}") @Retry @Timeout(100) @Asynchronous @Fallback(fallbackMethod = "fallback") public CompletionStage<String> onClientSide(@PathParam("parameter") String parameter) { return CompletableFuture.completedFuture("We are live @" + conf+ "! "+ service.doSomething(parameter)); } public CompletionStage<String> fallback(@PathParam("parameter") String parameter) { return CompletableFuture.completedFuture("This is my fallback!"); } }

10. Dev/prod parity

The best practice of operating on microservices is keeping development, staging, and production environments as similar as possible in terms of code, people, and environment. Docker images are here to ensure that the environments stay the same so that you don’t run into the problem of “it runs on my laptop”.

SEE ALSO: Kubernetes: How to use readiness, liveness, and startup probes

11. Logs

Treat logs as event streams. The best practice is to system out your logs in JSON format and directly feed to ELK.

12. Admin processes

You should manage admin processes using Kubernetes Jobs so that the process will terminate automatically. You should not bake the admin processes into your microservices.

In summary, using MicroProfile and Kubernetes enables you to build a 12 Factor App. The code examples can be found from the following locations:

https://github.com/Emily-Jiang/vsummit-12factor-app-a

https://github.com/Emily-Jiang/vsummit-12factor-app-b

https://github.com/Emily-Jiang/vssummit-12factor-deployment

References

https://microprofile.io

https://openliberty.io

https://quarkus.io

https://www.12factor.net/

https://kubernetes.io/

https://github.com/Emily-Jiang/vsummit-12factor-app-a

https://github.com/Emily-Jiang/vsummit-12factor-app-b

https://github.com/Emily-Jiang/vssummit-12factor-deployment

0 notes

holytheoristtastemaker · 5 years ago

Quote

Quarkus is a new technology aimed at cloud development. With Quarkus, you can take advantage of smaller runtimes optimized for the cloud. You don’t need to relearn new APIs. Quarkus is built on top of the best-of-breed technologies from the last decade, like Hibernate, RESTEasy, Vert.x, and MicroProfile. Quarkus is productive from day one. Quarkus is production ready. Quarkus created quite a buzz in the enterprise Java ecosystem in 2019. Like all other developers, I was curious about this new technology and saw a lot of potential in it. What exactly is Quarkus? How is it different from other technologies established in the market? How can Quarkus help me or my organization? Let’s find out. What is Quarkus? The Quarkus project dubbed itself Supersonic Subatomic Java. Is this actually real? What does this mean? To better explain the motivation behind the Quarkus project, we need to look into the current state of software development. From On-Premises to Cloud The old way to deploy applications was to use physical hardware. With the purchase of a physical box, we paid upfront for the hardware requirements. We had already made the investment, so it wouldn’t matter if we used all the machine resources or just a small amount. In most cases, we wouldn’t care that much as long as we could run the application. However, the Cloud is now changing the way we develop and deploy applications. In the Cloud, we pay exactly for what we use. So we have become pickier with our hardware usage. If the application takes 10 seconds to start, we have to pay for these 10 seconds even if the application is not yet ready for others to consume. Java and the Cloud Do you remember when the first Java version was released? Allow me to refresh your memory — it was in 1996. There was no Cloud back then. In fact, it only came into existence several years later. Java was definitely not tailored for this new paradigm and had to adjust. But how could we change a paradigm after so many years tied to a physical box where costs didn’t matter as much as they do in the Cloud? It’s All About the Runtime The way that many Java libraries and frameworks evolved over the years was to perform a set of enhancements during runtime. This was a convenient way to add capabilities to your code in a safe and declarative way. Do you need dependency injection? Sure! Use annotations. Do you need a transaction? Of course! Use an annotation. In fact, you can code a lot of things by using these annotations that the runtime will pick and handle for you. But there is always a catch. The runtime requires a scan of your classpath and classes for metadata. This is an expensive operation that consumes time and memory. Quarkus Paradigm Shift Quarkus addressed this challenge by moving expensive operations like Bytecode Enhancement, Dynamic ClassLoading, Proxying, and more to compile time. The result is an environment that consumes less memory, less CPU, and faster startup. This is perfect for the use case of the Cloud, but also useful for other use cases. Everyone will benefit from less resources consumption overall, no matter the environment. Maybe Quarkus is Not So New Have you heard of or used technologies such as CDI, JAX-RS, or JPA? If so, the Quarkus stack is composed of these technologies that have been around for several years. If you know how to develop these technologies, then you will know how to develop a Quarkus application. Do you recognize the following code? @Path("books") @Consumes(APPLICATION_JSON) @Produces(APPLICATION_JSON) public class BookApi { @Inject BookRepository bookRepository; @GET @Path("/{id}") Response get(@PathParam("id")Long id) { return bookRepository.find(id) .map(Response::ok) .orElse(Response.status(NOT_FOUND)) .build(); } } Congratulations, you have your first Quarkus app! Best of Breed Frameworks and Standards The Quarkus programming model is built on top of proven standards, be it official standards or de facto standards. Right now, Quarkus has first class support for technologies like Hibernate, CDI, Eclipse MicroProfile, Kafka, Camel, Vert.x, Spring, Flyway, Kubernetes, Vault, just to name a few. When you adopt Quarkus, you will be productive from day one since you don’t really need to learn new technologies. You just use what has been out there for the past 10 years. Are you looking to use a library that isn’t yet in the Quarkus ecosystem? There is a good chance that it will work out of the box without any additional setup, unless you want to run it in GraalVM Native mode. If you want to go one step further, you could easily implement your own Quarkus extension to provide support for a particular technology and enrich the Quarkus ecosystem. Quarkus Setup So, you may be asking if there is something hiding under the covers. In fact yes there is. You are required to use a specific set of dependencies in your project that are provided by Quarkus. Don’t worry, Quarkus supports both Maven and Gradle. For convenience, you can generate a skeleton project in Quarkus starter page, and select which technologies you would like to use. Just import it in your favorite IDE and you are ready to go. Here is a sample Maven project to use JAX-RS with RESTEasy and JPA with Hibernate: 4.0.0 org.acme code-with-quarkus 1.0.0-SNAPSHOT 3.8.1 true 1.8 1.8 UTF-8 UTF-8 1.3.0.Final quarkus-universe-bom io.quarkus 1.3.0.Final 2.22.1 ${quarkus.platform.group-id} ${quarkus.platform.artifact-id} ${quarkus.platform.version} pom import io.quarkus quarkus-resteasy io.quarkus quarkus-junit5 test io.rest-assured rest-assured test io.quarkus quarkus-hibernate-orm io.quarkus quarkus-resteasy-jsonb io.quarkus quarkus-maven-plugin ${quarkus-plugin.version} build maven-compiler-plugin ${compiler-plugin.version} maven-surefire-plugin ${surefire-plugin.version} org.jboss.logmanager.LogManager You might have noticed that most of the dependencies start with the groupId io.quarkus and that they are not the usual dependencies that you might find for Hibernate, Resteasy, or Junit. Quarkus Dependencies Now, you may be wondering why Quarkus supplies their own wrapper versions around these popular libraries. The reason is to provide a bridge between the library and Quarkus to resolve the runtime dependencies at compile time. This is where the magic of Quarkus happens and provides projects with fast start times and smaller memory footprints. Does this mean that you are constrained to use only Quarkus specific libraries? Absolutely not. You can use any library you wish. You run Quarkus applications on the JVM as usual, where you don’t have limitations. GraalVM and Native Images Perhaps you already heard about this project called GraalVM by Oracle Labs? In essence, GraalVM is a Universal Virtual Machine to run applications in multiple languages. One of the most interesting features is the ability to build your application in a Native Image and run it even faster! In practice, this means that you just have an executable to run with all the required dependencies of your application resolved at compile time. This does not run on the JVM — it is a plain executable binary file, but includes all necessary components like memory management and thread scheduling from a different virtual machine, called Substrate VM to run your application. For convenience, the sample Maven project already has the required setup to build your project as native. You do need to have GraalVM in your system with the native-image tool installed. Follow these instructions on how to do so. After that, just build as any other Maven project but with the native profile: mvn verify -Pnative. This will generate a binary runner in the target folder, that you can run as any other binary, with ./project-name-runner. The following is a sample output of the runner in my box: [io.quarkus] (main) code-with-quarkus 1.0.0-SNAPSHOT (powered by Quarkus 1.3.0.Final) started in 0.023s. Listening on: http://0.0.0.0:8080 INFO [io.quarkus] (main) Profile prod activated. [io.quarkus] (main) Installed features: [agroal, cdi, hibernate-orm, narayana-jta, resteasy, resteasy-jsonb] Did you notice the startup time? Only 0.023s. Yes, our application doesn’t have much, but still pretty impressive. Even for real applications, you will see startup times in the order of milliseconds. You can learn more about GraalVM on their website. Developer Productivity We have seen that Quarkus could help your company become Cloud Native. Awesome. But what about the developer? We all like new shiny things, and we are also super lazy. What does Quarkus do for the developer that cannot be done with other technologies? Well, how about hot reloading that actually works without using external tools or complicated tricks? Yes, it is true. After 25 years, since Java was born, we now have a reliable way to change our code and see those changes with a simple refresh. Again, this is accomplished by the way Quarkus works internally. Everything is just code, so you don’t have to worry about the things that made hot reloading difficult anymore. It is a trivial operation. To accomplish this, you have to run Quarkus in Development Mode. Just run mvn quarkus:dev and you are good to go. Quarkus will start up and you are free to do the changes to your code and immediately see them. For instance, you can change your REST endpoint parameters, add new methods, and change paths. Once you invoke them, they will be updated reflecting your code changes. How cool is that? Is Quarkus Production Ready? All of this seems to be too good to be true, but is Quakus actually ready for production environments? Yes it is. A lot of companies are already adopting Quarkus as their development/runtime environment. Quarkus has a very fast release cadence (every few weeks), and a strong Open Source community that helps every developer in the Java community, whether they are just getting started with Quarkus or are an advanced user. Check out this sample application that you can download or clone. You can also read some of the adoption stories in a few blog posts so you can have a better idea of user experiences when using Quarkus. Conclusion After a year of its official announcement, Quarkus is already on version 1.3.1.Final. A lot of effort is being put in the project to help companies and developers to write applications that they can run natively in the Cloud. We don’t know how far Quarkus can go, but one thing is for certain: Quarkus shook the entire Java ecosystem in a space dominated by Spring. I think the Java ecosystem can only win by having multiple offerings that can push each other and innovate to keep themselves competitives.

http://damianfallon.blogspot.com/2020/04/getting-started-with-quarkus.html

#SEO #Local SEO training

0 notes