Modern Java in the Cloud, Part 1: Introducing MicroProfile

This is the first post in a series where we walk through everything you need to do to have a Java or Kotlin application deployed and available for your users fast, with negligible amount of managing, wiring, and infrastructure work.

MicroProfile is what you need to solve the generic technical problems you will run into when building a Java microservice architecture.

A bold statement, but my experience so far emphasizes the impression. MicroProfile is a set of standards, of which some empower your Java code inside each application, whereas others focus on running the application inside a containerized environment. Other specifications again focus on the communication between your different microservices. And of course, some of those overlap, for instance the JSON support.

MicroProfile originated as a reaction to Java EE becoming stale, and the first three specifications were actually taken directly from Java EE: CDI, Jax-RS and JSON-B. That is, in most cases, dependency injection, REST endpoints and support for JSON request and return objects. Once the organizational issues were sorted out, new specifications arose on top of these, and MicroProfile grew into its own thing.

Since then, Java EE has become Jakarta EE, and new releases have reached the market. The latest one is Jakarta EE 10, which introduced the concept of the Core Profile. Dependency injection, Jakarta Restful Web Services and JSON bindings are the essential building blocks of this profile, so it’s perhaps needless to say that this profile has been established as a collaboration between the architects of Jakarta EE and MicroProfile.

Before heading further, let us introduce the different specifications and give a brief introduction to each of them.

• Jakarta EE Core Profile, which we just described in the previous section.
• Health supports the Kubernetes standard of probes for liveness, readiness and startup. It is perhaps the specification that is clearest on the intention of MicroProfile as cloud native.
• JWT authentication lets you use JSON Web Tokens as authentication bearers, which is growing into being the industry standard these days.
• Metrics provides data of how your application is running in terms of generic measures like CPU usage, memory usage and so on, and also lets you write your own custom metric. How many users have put an item into the shopping bin, for instance.
• Fault tolerance is what you need when doing calls to other services. They might be down or responding slowly, so you’ll need to be able to retry doing your remote calls, throttle how many calls you make towards a given service, or if all others fail do a fallback to another solution.
• Config lets you inject your environment variables directly as objects into your code, using dependency injection. That way you can easily use the same container image in different environments.
• Rest Client gives you a type safe way of doing REST calls.
• OpenAPI provides documentation for your REST endpoints, and allows you to specify details about your endpoints, parameters and return values.
• Telemetry is the newest specification. It focuses on observability. It’s focused on tracing calls spanning multiple services.

In addition to these, there are standalone specifications under the MicroProfile umbrella. These may be worth looking into if you are in the relevant context:

• Long-running actions
• GraphQL
• Context propagation
• Reactive messaging
• Reactive streams operators
• OpenTracing (although this one is deprecated, use Telemetry instead)

That’s quite a few specifications. Luckily, you would not have to implement them yourself, as there are several runtimes that provide the implementation for you.

Here is the complete list of runtimes supporting MicroProfile[1]:

• Payara Micro
• Apache TomEE
• Launcher by Fujitsu
• OpenLiberty by IBM
• kumuluzEE
• Helidon by Oracle
• Quarkus by RedHat
• WildFly by Redhat

Several of these runtime vendors are represented in the working group as well. Projects underneath the Eclipse umbrella each have a working group guiding and securing the progress. The working group for Eclipse MicroProfile consists of representatives from IBM, Fujitsu, RedHat, Oracle, Payara and Tomitribe as well as Microsoft, Primeton, Hunan AsiaInfo Anhui, Atlanta Java Users Group (JUG), Garden State JUG and iJUG (the association of German JUGs).

Where Java EE was a product of and solely controlled and developed by Oracle, Jakarta EE is now fully open source and managed through the Eclipse Foundation. That means that MicroProfile and Jakarta EE are under the same organizational umbrella, which I imagine will make the mercantile issues easier.

To elaborate on that thought: It will be interesting to see what the future will look like for MicroProfile. Will it continue as its own concept, or will it eventually become a profile inside Jakarta EE?

Regardless of the mercantile and organizational further direction, I’m fully convinced that MicroProfile is just what Java or Kotlin developers working in a microservice architecture need.

In the next post in this series, we’ll look at lifting our application from our own computer into the cloud.

[1]: Fetched from https://docs.google.com/presentation/d/1zv84tq7SGRIpzPfxFQVAdVNT2jQvadjt/edit#slide=id.p6

---

Modern Java in the Cloud, Part 1: Introducing MicroProfile was originally published in Compendium on Medium, where people are continuing the conversation by highlighting and responding to this story.