What are the benefits of using MicroProfiles
MicroProfile specifications are an effort to provide solutions for some of the common challenges developers face when running microservices in the cloud, such as separating configurations from applications, handling REST clients or making your microservices more fault tolerant. The main intention behind the development of MicroProfiles is to be used in microservices, so naturally this is where they will provide the most benefits. Nevertheless, MicroProfiles can also be used in any ordinary application (EAR, WAR) running in an application server.
MicroProfile specifications haven’t been designed from scratch but have been provided by open source communities and companies such as Deltaspike, Uber or Narayana. MicroProfiles are developed under the umbrella of the eclipse foundation and will hopefully become a full Jakarta-Enterprise-Edition specification in the future.
There are several MicroProfile Projects as you can see here. The following discussed MicroProfiles are those which I have written articles about.
MicroProfile-Rest-Client provides a type-safe way to invoke REST endpoints via an interface which defines the REST endpoint with JAX-RS annotations. This MicroProfile is interoperable with MicroProfile-Config but unfortunately not with MicroProfile-Opentracing, but I’m sure this feature will come soon. Nevertheless, the opentracing-contrib community provides a JAX-RS feature which integrates MicroProfile-Opentracing into JAX-RS clients and server endpoints.
MicroProfile-Opentracing provides mechanisms for tracing your method and service invocations. In a microservice environment it’s absolutely necessary to trace your service invocations for problem analysis. This MicroProfile has been provided by Uber along with the Jaeger-UI which is the UI where you analyse your traces. The opentracing-contrib community provides useful features for tracing different aspects of your application such as database interactions.
MicroProfiles with Wildfly/EAP
The Wildfly application server supplies integrated MicroProfile capabilities since version 14. The developer has to add a provided dependency for the MicroProfile API and has to ensure he uses the proper version of the Wildfly integrated MicroProfile capability. JBoss Enterprise Application Platform (EAP) on the other hand is the supported version of the Wildfly application server and integrates fewer MicroProfile capabilities, whereby these MicroProfile capabilities are for now only available as tech preview. –> more information
MicroProfiles with Thorntail
In my opinion, Thorntail was the first JEE framework which made it possible to deploy a JEE application as a microservice to the cloud. Thorntail provides dependencies, so called Fractions, which are similar to Wildfly/EAP Modules, whereby a Fraction provides one JEE specification or, put differently, one aspect you want to use in the application such as JPA, CDI, JAX-RS, JAX-RS-JSONB and so on. A Fraction provides the compile time dependencies for the development and also the runtime dependencies Thorntail uses to package the microservice. In fact, Thorntail only takes the packaged WAR-Archive and repackages it into a standalone fat/ueber jar, whereby it builds a partial Wildfly Server within the fat/ueber jar depending on the used Fractions. Consequently Thorntail is completely transparent to your application and there will never be the need to import to a Thorntail namespace in your source code.
Thorntail is a supported application runtime by RedHat since the 2019, nevertheless that Thorntail has been deprecated shortly after RedHat made it general available. But this is not a problem, because Thorntail is only present in your pom.xml and not in your source code. Thorntail will be replaced by Quarkus which is also only present in your pom.xml, so migrations should be fairly easy.
MicroProfile with Quarkus
Quarkus is a relatively new Framework which is very similar to Thorntail. It provides Tooling for creating a native image, whereby your application will be compiled to a native binary and packaged into a Linux container. The main aim of Quarkus is to provide a tool which helps us to create cloud native applications and uses GraalVM to get rid of the VM overhead by building native images capable of running in the cloud. Quarkus handles similar to Thorntail, for instance what was called a Fraction in Thorntail is now called an Extension in Quarkus.