Why Should You Consider Using MicroProfile In Your Microservices?

A Little Bit of History

“Write once, run anywhere” was the slogan created by Sun Microsystems in 1995 when the first Java version came out. One of the things that allowed this was the creation of specifications for the Java Language and the Java Virtual Machine.

With those specifications, we don’t have to worry about how a feature was implemented. Every implementation must run a Technology Compatibility Kit (TCK), which consists of a suite test that guarantees that the runtime implements all the specifications.

Four years after Java was released, the community created the Enterprise Edition of the Java Platform (Java 2 Platform, Enterprise Edition or J2EE).

It consisted of several specifications that solved common challenges faced when creating enterprise applications. A few years later, the platform would be renamed to “Java Platform, Enterprise Edition” (or Java EE) and after Oracle (the Java EE maintainer) submit the platform to Eclipse Foundation, it would be renamed again to “Jakarta EE”.

The Downsizing Trend

The first implementations of the enterprise specifications were big, heavy, and the applications took several minutes to start up. A few years later the trend was “lighter is better” and the Java EE implementations started to pursuit it.

One of the most known implementations is Apache TomEE, which consists of Jakarta EE and MicroProfile on Apache Tomcat.

As David Blevins (a very important name in OSS, CEO of Tomitribe and a founder of Apache TomEE) stated in Tomitribe blog, the first version of TomEE, announced in 2011, was a 30MB distro which booted in a second, ran with default 64MB JVM heap and passed the Java EE 6 Web Profile TCK on hundreds of t1.micro servers in Amazon EC2. For David, that was a foreshadowing of the microservices movement.

The Microservices Era

The microservices architecture arrived, quickly became a hype, and the companies were solving the same problems each one in its way. That aroused the need for a standard.

But we know that in Software Engineering every solution has a trade-off, and the use of a standard is not different. Creating a standard may take much time.

It was then that, in 2016, supported by the Java Community and companies like RedHat, IBM, Tomitribe, Payara, and LJC, was created MicroProfile, defined in the official site as a baseline platform definition that optimizes Enterprise Java for microservices architecture and delivers application portability across multiple MicroProfile runtimes. Its approach allows vendors, the community, and open-source projects to innovate while collaborating where there is a commonality. This will occur at a much faster pace than a standard.


At the time this post is written, MicroProfile 3.3 has 12 specifications:

  1. MicroProfile Config
  2. Used to inject configuration properties from external sources, like property files, environment or system variables
  3. Contexts and Dependency Injection (CDI)
  4. Used to provide a typesafe dependency injection mechanism
  5. MicroProfile Fault Tolerance
  6. Used to provide a set of strategies to build resilient and fault-tolerant services
  7. MicroProfile Health
  8. Used to add liveness and readiness checks to determine the application’s health
  9. Jakarta RESTful Web Services (JAX-RS)
  10. Used to develop web services following the REST pattern
  11. JSON Binding (JSON-B)
  12. Used to convert Java objects from and to JSON
  13. JSON Processing (JSON-P)
  14. Process JSON messages (parse, generate, transform and query)
  15. MicroProfile JWT Auth
  16. Used to provide JWT token-based authentication for the application
  17. MicroProfile Metrics
  18. Used to add custom metrics, like timers or counters, to the application and expose them via HTTP
  19. MicroProfile OpenAPI
  20. Used to provide a unified Java API for the OpenAPI v3 specification to expose API documentation
  21. MicroProfile OpenTracing
  22. Used to provide distributed tracing for a JAX-RS application using the OpenTracing standard
  23. MicroProfile Rest Client
  24. Used to provide type-safe clients to invoke RESTful Web Services

Compliant Runtimes

At the time of this post, the MicroProfile Starter lists 9 MicroProfile compliant runtimes that you can use to run your applications and you’re free to choose any of them.

  • Apache TomEE
  • Helidon
  • KumuluzEE
  • Open Liberty
  • Payara Micro
  • Quarkus
  • Thorntail
  • WildFly
  • WildFly Swarm


When we use MicroProfile we are free to choose any compliant runtime and the slogan “Write once, run anywhere” becomes great again. Being able to move our applications to different runtimes gives us the freedom to choose the best vendor for our needs, and when we’re no longer satisfied, or if a better one comes up, we can just switch it, since we’re avoiding the vendor lock-in.

Besides that, MicroProfile has an engaged community continuously enhancing the platform and working on common problems that all of us would have to solve by ourselves, like configuration, metrics, health check, or tracing. So we can focus on what matters when writing an application: the business logic.

To participate, you can join the discussion and contribute in many ways, like giving feedback, sharing your needs, proposing new features or specifications, and even fixing bugs. The platform is made by and for the community.

Leave a Reply

Your email address will not be published. Required fields are marked *