One-year anniversary: A look at Eclipse MicroProfile
© Shutterstock / Black
MicroProfile is one year old. In this article, Martijn Verburg explores the fast-moving Eclipse MicroProfile, which promises to make it easier for developers to use Java to build microservices.
How time flies! MicroProfile is one year old already.
MicroProfile is currently going through a logo redesign, so don’t forget to vote for your favorite logo:
— Eclipse MicroProfile (@MicroProfileIO) July 10, 2017
The Java community has likely been the greatest factor in Java’s success and influence over the past 20+ years. This community has rallied and collaborated to improve the language and its capabilities through JSRs, libraries, APIs, frameworks, and more. Java EE, in particular, has become “the dominant standard for companies building business-critical, multi-tier enterprise applications.”
However, times are changing, with microservices architectures becoming ever more popular as monolithic applications hinder the advances of continuous delivery and integration. Traditional enterprise Java applications are also increasingly difficult to troubleshoot performance, leading to downtimes that are unacceptable for today’s businesses.
To meet this challenge, we are now seeing a proliferation of micro services frameworks within the Java/JVM ecosystem including but not limited to Spring Boot, Ratpack, Vert.x (a personal favorite) and Lagom.
Eclipse MicroProfile (aka Microprofile.io) is the latest entry into this space which is aimed at providing microservices features to developers that typically come from an Enterprise Java background.
It’s gathered a great deal of interest with its fast moving collaborative approach, defining a set of APIs around areas such as configuration, service discovery, health checks and much more.
Why Eclipse MicroProfile?
The motivation behind MicroProfile came from traditional Enterprise Java developers who utilized Java EE technologies and were looking for micro service features such as service discovery, health checks, circuit breakers and much more. The MicroProfile project tagline echoes this sentiment:
“Optimising Enterprise Java for a Microservices Architecture”
The Java EE community also wanted to avoid fragmentation. Each vendor and various individual community innovators were approaching the micro services space in a slightly different way. In the spirit of open source and open communities, they decided instead to collaborate and do so in a way that no one vendor or individual can dominate.
Why not just use Java EE?
Java EE is a set of standards which take the best of competing implementations. But, by its very nature, it is always going to lag behind what the bleeding edge of the industry needs. To put it into perspective, if work on Java EE 9 were to begin today with the intent of addressing microservices, most vendors would not have a supported implementation until ~2019. That’s simply too long for the community to wait for microservices support.
The MicroProfile project does value choice of implementation. Standards enable multiple implementations and users can choose which implementation to deploy, perhaps based on security, price, performance, value-add features, existing relationships, etc. This is a very different value proposition from an open source project dominated by a single vendor.
The MicroProfile project is looking to rapidly explore various APIs and ideas and may apply them to the appropriate standards body, perhaps the Java Community Process (JCP) where Java EE standards come from.
Who’s behind Eclipse MicroProfile?
Eclipse MicroProfile is being driven by several software vendors including RedHat, IBM, Tomitribe, Payara, Fujitsu and Hazelcast, as well as several Java user groups including SouJava and the London Java Community.
It’s very much a community-driven project; the community votes on the next microservice features they’d like to see included and collaboratively work on APIs together.
What’s the current version?
MicroProfile 1.0 was unveiled at JavaOne in September 2016 and provided functionality for applications to consume JSON over a RESTful interface with dependency injection support for services via existing Java EE standards (JAX-RS, JSON-P and CDI). A demo conference application was created showcasing that each vendor could independently run microservices of that application. With the move to the Eclipse Foundation, a formal release of MicroProfile 1.0 will occur shortly with the artifacts being placed in Maven central.
MicroProfile 1.1, targeted for the 2nd quarter of 2017, will build on top of the initial release adding:
- Health checks
- Monitoring and metrics
- JWT based security
- And possibly more!
These new features may utilize some Java EE standards but will also look to leverage popular open source technologies. The discussions around what will be built and how, are all on the mailing list, with all of the vendors, as well as day to day developers, helping design the next set of APIs.
What runtimes support MicroProfile?
A number of respected vendors support the full MicroProfile architecture including:
- WildFly Swarm from RedHat
- WebSphere Liberty from IBM
- Payara (based on Glassfish) from Payara
- TomEE from Tomitribe
Hazelcast and Fujitsu are also supporting members who intend on implementing part of the MicroProfile specification.
Get involved in Eclipse MicroProfile
There’s a great amount of choice for Java developers looking for a microservices framework. Spring developers will naturally gravitate towards Spring Boot, Scala / Akka developers will most likely use Lagom, and polyglot developers are well served by Vert.x.
However, if you’re one of the millions of Enterprise Java developers out there today and/or you have a strong Java EE background then Eclipse Microprofile is well worth a look! Even better is that you have the opportunity to shape its direction and implementation as new microservice requirements come to the fore.
Here are some further resources to help get you started: