Skip to content
Home » Why Should You Consider Using MicroProfile In Your Microservices?

Why Should You Consider Using MicroProfile In Your Microservices?

MicroProfile

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 thing 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 comprises 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 comprised 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 Red Hat, 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.

Specifications

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

  1. MicroProfile Config
  2. Contexts and Dependency Injection (CDI)
  3. MicroProfile Fault Tolerance
  4. MicroProfile Health
  5. Jakarta RESTful Web Services (JAX-RS)
  6. JSON Binding (JSON-B)
  7. JSON Processing (JSON-P)
  8. MicroProfile JWT Auth
  9. MicroProfile Metrics
  10. MicroProfile OpenAPI
  11. MicroProfile OpenTracing
  12. MicroProfile Rest Client

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

Conclusion

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.