Source – https://www.infoq.com/
Key Takeaways
- Since 2018, several new microservices frameworks – including Micronaut, Helidon and Quarkus – have been introduced to the Java community, and have made an impact on microservices-based and cloud-native applications development.
- The MicroProfile community and specification was created to enable the more effective delivery of microservices by enterprise Java developers. This effort has influenced how developers are currently designing and building applications.
- MicroProfile will continue to evolve with changes to its current APIs and most likely the creation of new APIs.
- Developers should familiarize themselves with Heroku’s “Twelve-Factor App,” a set of guiding principles that can be applied with any language or framework in order to create cloud-ready applications.
- When it comes to the decision to build an application using either a microservices or monolithic style, developers should analyze the business requirements and technical context before choosing the tools and architectures to use.
In mid-2016, two new initiatives, MicroProfile and the Java EE Guardians (now the Jakarta EE Ambassadors), had formed as a direct response to Oracle having stagnated their efforts with the release of Java EE 8. The Java community felt that enterprise Java had fallen behind with the emergence of web services technologies for building microservices-based applications.
Introduced at Red Hat’s DevNation conference on June 27, 2016, the MicroProfile initiative was created as a collaboration of vendors – IBM, Red Hat, Tomitribe, Payara – to deliver microservices for enterprise Java. The release of MicroProfile 1.0, announced at JavaOne 2016, consisted of three JSR-based APIs considered minimal for creating microservices: JSR-346 – Contexts and Dependency Injection (CDI); JSR-353 – Java API for JSON Processing (JSON-P); and JSR-339 – Java API for RESTful Web Services (JAX-RS).
By the time MicroProfile 1.3 was released in February 2018, eight community-based APIs, complementing the original three JSR-based APIs, were created for building more robust microservices-based applications. A fourth JSR-based API, JSR-367 – Java API for JSON Binding (JSON-B), was added with the release of MicroProfile 2.0.
Originally scheduled for a June 2020 release, MicroProfile 4.0 was delayed so that the MicroProfile Working Group could be established as mandated by the Eclipse Foundation. The working group defines the MicroProfile Specification Process and a formal Steering Committee composed of organizations and Java User Groups (JUGs), namely Atlanta JUG, IBM, Jelastic, Red Hat and Tomitribe. Other organizations and JUGs are expected to join in 2021. The MicroProfile Working Group was able to release MicroProfile 4.0 on December 23, 2020 featuring updates to all 12 core APIs and alignment with Jakarta EE 8.
The founding vendors of MicroProfile offered their own microservices frameworks, namely Open Liberty (IBM), WildFly Swarm/Thorntail (Red Hat), TomEE (Tomitribe) and Payara Micro (Payara), that ultimately supported the MicroProfile initiative.
In mid-2018, Red Hat renamed WildFly Swarm, an extension of Red Hat’s core application server, WildFly, to Thorntail to provide their microservices framework with its own identity. However, less than a year later, Red Hat released Quarkus, a “Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best-of-breed Java libraries and standards.” Dubbed “Supersonic Subatomic Java,” Quarkus quickly gained popularity in the Java community to the point that Red Hat announced Thorntail’s end-of-life in July 2020. Quarkus joined the relatively new frameworks, Micronaut and Helidon, that were introduced to the Java community less than a year earlier. With the exception of Micronaut, all of these microservices-based frameworks support the MicroProfile initiative.
The core topics for this virtual panel are threefold: first, to discuss how microservices frameworks and building cloud-native applications have been influenced by the MicroProfile initiative. Second, to explore the approaches to developing cloud-native applications with microservices and monoliths, and also the recent trend in reverting back to monolith-based application development. And third, to debate several best practices for building microservices-based and cloud-native applications.
