Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
This article explains what Eclipse JKube Remote Development is and how it helps developers build Kubernetes-native applications with Quarkus.
As mentioned in my previous article, microservices don’t exist in a vacuum. They typically communicate with other services, such as databases, message brokers, or other microservices. Because of this distributed nature, developers often struggle to develop (and test) individual microservices that are part of a larger system.
Microservices today are often deployed on a platform such as Kubernetes, which orchestrates the deployment and management of containerized applications. Microservices, however, don't exist in a vacuum. They typically communicate with other services, such as databases, message brokers, or other microservices. Therefore, an application usually consists of multiple services that form a complete solution.
But, as a developer, how do you develop and test an individual microservice that is part of a larger system? This article examines some common inner-loop development cycle challenges and shows how Quarkus and other technologies help solve some of these challenges.
Are you building microservices? Do you struggle with observability and with capturing telemetry data between distributed services? This article shows how to quickly and easily introduce OpenTelemetry into a distributed system built on Java with Quarkus. This combination allows you to visualize the interactions between all the microservices within an overall system.
The article introduces the official Quarkus sample application, Quarkus Superheroes, deploys it on the free Developer Sandbox for Red Hat OpenShift, and demonstrates how to collect and visualize telemetry data in order to observe microservices' behavior.
The tools available in the Spring ecosystem make it easy to get started with building applications. However, the same is true for Quarkus, which has many additional features and capabilities aimed at improving the developer experience. A Spring developer can quickly get started working with a Quarkus project and immediately become more productive, as we'll see in this article. Plug-ins and tooling are available for most major IDEs, including VSCode, IntelliJ, and Eclipse.
A Spring developer’s starting point is the Spring Initializr, which can be used directly from the website, as shown in Figure 1, or via plug-ins for most major IDEs.
As interest grows in microservices and containers, Java developers have struggled to make applications smaller and faster to meet today’s demands and requirements. In the modern computing environment, applications must respond to requests quickly and efficiently, be suitable for running in volatile environments such as virtual machines or containers, and support rapid development. Because of this, Java, and popular Java runtimes, are sometimes considered inferior to runtimes in other languages such as Node.js and Go.
The Java language and the Java platform have been very successful over the years, preserving Java as the predominant language in current use. Analysts have estimated the global application server market size at $15.84 billion in 2020, with expectations of growing at a rate of 13.2% from 2021 to 2028. Additionally, tens of millions of Java developers worldwide work for organizations that run their businesses using Java. Faced with today’s challenges, these organizations need to adapt and adopt new ways of building and deploying applications. Forgoing Java for other application stacks isn’t a choice for many organizations. It would involve re-training their development staff and re-implementing processes to release and monitor applications in production.
Since its inception, Quarkus has focused on more than just delivering sets of features. Developer productivity and joy have been critical components of Quarkus. The developer experience and how to improve it are carefully considered with every new feature added. This article showcases the maturity and evolution of developer productivity capabilities within Quarkus from inception to the newly-released version 2.0.
Quarkus rests on a vast ecosystem of technologies, standards, libraries, and APIs, making Quarkus “familiar” but “new”. Developers don’t have to spend lots of time learning an entirely new set of APIs and technologies to take advantage of the benefits Quarkus brings to the JVM or native images. Instead, developers can utilize their existing knowledge and skills. Among the specifications and technologies underlying Quarkus are Eclipse MicroProfile, Eclipse Vert.x, Contexts & Dependency Injection (CDI), JAX-RS, the Java Persistence API (JPA), the Java Transaction API (JTA), Apache Camel, and Hibernate, just to name a few.
Since the invention of the Java language, there has been a long-standing debate about checked versus unchecked/runtime exceptions. Some people argue that checked exceptions promote a better design. Others feel that checked exceptions get in the way, especially as systems mature and refactor over time, and therefore unchecked exceptions are better. The Effective Java Exceptions article settles this debate once and for all: both checked and unchecked exceptions are acceptable, and each has its purpose within an application. I highly recommend reading that article. I will refer back to its concepts and terminology going forward.
Exception handling is an important part of the design and architecture of an application. It represents alternate flows or scenarios other than the "happy path" flow through an application. Generally, business requirements only tell you how the application should behave when everything happens as expected. They rarely describe what to do when something goes wrong.
Quarkus is a Java stack tailored for OpenJDK HotSpot (or OpenJ9 on zSeries) and GraalVM, crafted from optimized Java libraries and standards. It is a good choice for building highly-scalable applications while using lower amounts of CPU and memory resources than other Java frameworks. These applications can be traditional web applications, serverless applications, or even functions as a service.
There are many documented instances of organizations migrating their applications to Quarkus. In this article, let's see one such migration path from Spring Boot to Quarkus that is part magic and part madness! The magic will be some hand waving and performing the migration without changing a single line of code. The madness will be trying to figure out how it was done.
gRPC is an open source remote procedure call (RPC) framework. It was released by Google in 2015 and is now an incubating project within the Cloud Native Computing Foundation. This post introduces gRPC while explaining its underlying architecture and how it compares to REST over HTTP. You'll also get started using Quarkus to implement and consume gRPC services.
Wait, what’s this? Did you say remote method calling? Isn’t that something we did in the ‘90s with things like CORBA, RMI, and XML-RPC/SOAP?
One question always comes up as organizations moving towards being cloud-native, twelve-factor, and stateless: How do you get an organization’s data to these new applications? There are many different patterns out there, but one pattern we will look at today is change data capture. This post is a simple how-to on how to build out a change data capture solution using Debezium within an OpenShift environment. Future posts will also add to this and add additional capabilities.
Another Red Hatter, Sadhana Nandakumar, sums it up well in one of her posts around change data capture: