James Roper, senior developer and co-creator of the Lagom microservices framework at Lightbend, was recently named a committer for Eclipse MicroProfile. He is the first committer representing Lightbend, a participating member of Jakarta EE.
In a recent blog post, Roper stated that his journey in being named a committer is related to the MicroProfile community and its influence on Jakarta EE. He noted that the four main contributors to MicroProfile are IBM, Red Hat, Tomitribe, and Payara. Roper stated:
IBM and RedHat are vendors whose investment in and share of the Java EE market is roughly comparable - they are the big companies that seem to be driving most of the work. Payara and Tomitribe are, in comparison, smaller companies who seem to have flourishing businesses built on supporting Glassfish and TomEE respectively, they are active in discussions and provide significant contributions themselves.
In addition to these four, there are a few other vendors that implement MicroProfile but seem to be less active in the community, and there are also a reasonable number of individuals, including Java Champions and Java EE Guardians, who are active in discussions. All of this indicates a healthy community - a mixture of vendors and individuals, some more active, some less active, but all working together for a common goal.
Based on the MicroProfile committers page, these four companies have the following represented number of committers relative to their respective size:
- IBM (21)
- Red Hat (17)
- Tomitribe (9)
- Payara (5)
Roper commented on the collaboration of all the companies in the MicroProfile community:
What makes this all the more amazing is that these vendors that are working together so well are actually fierce competitors. Their products are pitted directly against one another, and they are fighting hard to win market share from each other. However, they have still managed to find a way that they can work together for mutual benefit, and this has turned out to be both productive and innovative. This is why I think the MicroProfile community is a good sign for Jakarta EE.
Roper shared his experiences with InfoQ.
InfoQ: What was your motivation to join MicroProfile as a committer?
James Roper: I have always been motivated by making life easier for developers. This is what initially attracted me to Lightbend; Play Framework provided a fantastic developer experience on the JVM with its hot reloads and sensible opinionated defaults, and I wanted to be a part of delivering that experience to developers.
MicroProfile allows me to take that to the next level - Lightbend's open source projects may be widely used, but they don't have anywhere near the industry penetration that the Java standards have, the standards that MicroProfile and Jakarta EE are built on and are shaping. MicroProfile is an opportunity to bring the fantastic developer experience that we've been creating at Lightbend to a much broader audience.
InfoQ: What was the motivation for Lightbend to join Jakarta EE as a participating member?
Roper: One of the challenges that Lightbend has in growing its community is that our technology and approaches are often seen as too different from the rest of the industry, which makes adopting them high risk for reasons such as the difficulty of hiring developers with the right skills, and the difficulty of using them correctly when the developers you have don't understand them.
Involvement in Jakarta EE gives us a double edged sword to help address this.Firstly, it allows us to make our platform closer to the industry standards, by helping shape standards in a way that is compatible with our approach to microservices and cloud native systems so that we can implement the standards ourselves.
Secondly, it allows us to influence the industry standards to bring them closer to our approach, which we believe benefits both us and the entire Jakarta EE ecosystem, since we believe our Reactive approach to microservices is essential for building scalable and resilient systems.
InfoQ: How do you plan to contribute to MicroProfile?
Roper: My contribution (and the broader contributions of Lightbend) will primarily be around new Reactive specifications. The first thing we've done is help outline an approach for writing Reactive APIs and adopting Reactive features in MicroProfile. As a product of penning this approach, we identified that MicroProfile needs a Reactive Streams manipulation API, to allow MicroProfile developers to interact with Reactive Streams.
A specification for this API is well on its way to being finished. This leads into the next specification, called MicroProfile Reactive Messaging, which allows Reactive Streams based consuming, publishing and processing of messaging streams between services. This is where most of our focus is on at the moment.
Going forward, once these specs are complete, we will continue to look for ways that MicroProfile can benefit from Reactive approaches, and look to contribute in those areas. Just today the topic of MicroProfile persistence has come up, and at Lightbend we have a lot of experience solving the difficulties in persistence that don't occur in monoliths due to using a single database with ACID transactions, so I've joined those discussions and will seek to bring our experience to that.
InfoQ: Do you anticipate a Lagom microservices influence on MicroProfile? If so, in which specification (Config, CDI, JSON-P, Fault Tolerance, etc.) do you feel Lagom can most contribute?
Roper: To be honest, a lot of the work that has been done in MicroProfile so far has been playing catch up. Consider JSON support, the industry practically standardized on using JSON for communication around 10 years ago, yet Java EE only introduced an AST for JSON in 2013 with JSON-P in Java EE 7, and still today, no release of Java EE or MicroProfile has a standard API for binding Java objects to JSON. JSON-B is a specification that provides that, and it's scheduled for inclusion in the upcoming MicroProfile 2.0 and Java EE 8 releases.
Lagom on the other hand is built on technologies that have supported these basic features since before they were considered an industry standard - and so I don't think it's those types of features that Lagom brings the most value, for example there are plenty of good, mature solutions to JSON binding to model off out there, and Lagom obviously supports JSON binding and does it well, but so does every other good framework out there today. So it's not in the existing specifications that I think Lagom will have its biggest influence on MicroProfile.
Where Lagom brings unique value is in its support for building Reactive microservices, and that's really about taking the incredibly fragile world of cloud native computing, where anything can fail anywhere at any time, and applying patterns on top of it to ensure that developers can focus on solving their business problems rather than solving this fragility.
Implementing these patterns are where the industry has much less experience, there are far fewer products out there to base new specifications on, and even fewer that have broad industry adoption. These patterns require new architectures, and therefore new APIs, APIs for streaming, for asynchronous communication, for event log based persistence. So it's in the establishment and development of these new specifications that Lagom will have the biggest influence on MicroProfile.
InfoQ: What else would you like to share with our readers about MicroProfile and Jakarta EE?
Roper: I think a lot of people are skeptical about the role of standards in frameworks and APIs, which is understandable given how Oracle dropped the ball on the entire Java EE ecosystem. There are a few things to say about this:
1. Jakarta EE is free from the JCP and Oracle, and will not make the same mistakes again. The governance model that Eclipse has set up for Jakarta EE I believe strikes a very good balance between the role of the big vendors that invest most of the time and resources into developing and maintaining the specifications, implementations and tcks that make up Jakarta EE, and the role of merit based contributions from contributors who innovate and drive specifications forward. The fact that Lightbend was able to so easily go from a complete outsider to the MicroProfile and Jakarta EE communities, to having myself as the lead developer of a MicroProfile project, is a testament to this.
2. The open collaboration processes in place with Jakarta EE and MicroProfile is what makes standards based frameworks and APIs so valuable. In my short time contributing to these communities, I have learnt a lot about our industry and the different things that people are doing, what's important to them, and how they are solving their problems, things that I never would have learnt from staying in my Lightbend bubble.
Consequently, I believe the specs we're working on in MicroProfile, even though they draw heavily from our experience with Lagom, will be better than Lagom, due to that broader experience that is being fed into the process, and I look forward to going full circle and providing implementations of these specs in Lagom. So I believe the standards that Jakarta EE and MicroProfile produces in the years to come will be better than any one vendor could produce themselves.
3. I think a very important requirement that enterprise companies will have as they gradually embrace the cloud is, more than ever, the need to avoid vendor lock in. Previously, vendor lock in just meant being locked in to a particular application server and database, while you still controlled the hardware.
Now, it's not just the application server, it's the entire deployment infrastructure, from the servers, to the network, to the operating system, orchestration and of course still the application server and database. Cloud vendors are, more and more, pushing PaaS features because they are sticky, they lock you into their cloud offering. So lock in has a much higher cost to what it did before.
If you needed standards based frameworks to avoid lock in before, then you will need them even more now as you move to deploying your systems to the cloud. Jakarta EE and MicroProfile offer a way to mitigate against this lock in, allowing a PaaS offering that does not tie users to a particular cloud vendor, which leaves companies free to choose and switch between vendors based on who offers the best technology at any particular time.
InfoQ: What are your current responsibilities, that is, what do you do on a day-to-day basis?
Roper: My primary responsibilities, and what I spend most of my time on, are leading the MicroProfile Reactive project and creating the Reactive Messaging and Reactive Streams Support specifications. This includes coding (right now I'm starting on the TCK for Reactive Messaging), as well as having a lot of discussions on mailing lists, GitHub and in the weekly hangout.
In addition to this I spend a reasonable amount of time keeping up with the broader MicroProfile efforts, including attending the biweekly MicroProfile community hangout and being active on the mailing list. Recently I've also got involved in the CNCF CloudEvents spec (https://cloudevents.io/), as it is likely to form the basis for some of the APIs provided in MicroProfile Reactive Messaging, and that has included attending a number of hangouts, making proposals via PRs in GitHub and a lot of discussions in mailing lists and on GitHub.
InfoQ reached out to IBM, Red Hat, Tomitribe, and Payara to solicit their experiences on having successfully collaborated on MicroProfile despite being competitors.
Alasdair Nottingham, WebSphere and Liberty runtime architect at IBM, told InfoQ:
For the Liberty development team, partnering with our competition is nothing new. It has been core to our DNA since the first release of WebSphere (called Servlet Express) 1998, 20 years ago. At the time the then general manager of Java software at IBM, Pat Sueltz, said "We will cooperate on the specification but compete on the implementation" and that is what we have been doing ever since, whether on J2EE, Java EE, CommonJ or now Eclipse MicroProfile.
Although we have been collaborating on the APIs and specifications, anyone who has been watching the Java space knows that competition between the vendors is fierce; this is a good thing for the industry and the players. Without competition Apache Tomcat, Spring Boot, Wildfly or Liberty wouldn't exist today and we would be stuck with the heavyweight application servers of 10 years ago and Java would not be the strong platform for the cloud it is today.
This may all seem strange for those who aren't used to how Java EE (now Jakarta EE) has been evolving over the last 20 years, but to us the big difference that Eclipse MicroProfile has brought is not that we collaborate, but how we collaborate.
Adopting Open development models for defining the APIs (as well as the implementation) has allowed us to rapidly build out powerful new APIs for cloud-native Java. We don't always agree, but we all have a shared common goal which is to deliver a lightweight APIs for building the next wave of applications, based on the core of Java EE.
I think what the work we have been doing through Eclipse MicroProfile has shown is that an open approach to defining APIs can work very effectively and the Jakarta EE project is moving forward with a similarly open approach. The way that the Jakarta EE project is shaping up has been informed by the work done by Eclipse MicroProfile, but it has additional considerations.
MicroProfile started out to accelerate the adoption of a common cloud native programming on top of Java EE, one that is additive to Jakarta EE. Jakarta EE has to realign the Java EE technologies under the Eclipse Foundation as the starting point for ongoing work. So it is taking on and modernizing the processes we already have as well as taking the platform forward.
As Eclipse MicroProfile continues to define new APIs, there is a lot of interest and hope in the two projects working closely together, for example by Eclipse MicroProfile being an incubator for APIs which get consumed by JakartaEE, or as just two peer, but complementary projects. One thing I can say with confidence is that Eclipse MicroProfile and Jakarta EE do not, and will not conflict, there is just too much overlap in the community participants.
Mike Croft, senior middleware consultant at Red Hat, told InfoQ:
I think that James is absolutely right when he says that the success of MicroProfile is a good sign for how Jakarta EE will work. The fact is that despite being competitors, as James points out, the people involved from all vendors have known each other for a long time and appreciate that we all have a shared goal of success for Enterprise Java.
At its heart, MicroProfile is community-driven. Everything is done in the open, so everyone is accountable. In my view, this has been the key attribute that has made MicroProfile a success and it's exactly how Oracle has chosen to move forward with Jakarta EE, using a fully open approach to things like naming and the logo choice.
Where MicroProfile can have a large influence is around release strategy and more rapid innovation based upon real world experiences. Java EE has traditionally focused on major multi-year platform releases. MicroProfile, on the other hand, has been successful at delivering quarterly releases with incremental improvements that more readily adapts to the market and puts new features in developers' hands sooner. Jakarta EE will define its own release strategy, and can leverage MicroProfile's success and experience in this area.
David Blevins, founder and CEO at Tomitribe, told InfoQ:
Working alongside IBM, Red Hat and Payara to create the MicroProfile has been one of the proudest and most enjoyable moments in the history of Tomitribe and my own career. Oracle has consistently supported Tomitribe by providing many opportunities to shine and contribute. We have a great mutual respect and genuinely want to see each other succeed. As a former IBMer, I was among the crowd cheering and tweeting when OpenLiberty was released. When we announced Apache TomEE at JavaOne 2011, the Red Hat team was the first help us celebrate.
There have been times in our industry when competition wasn't so friendly. Trash talk, flame wars and astroturfing were commonplace. I think this is common in a young and naive industry where innovation is falsely perceived to be a zero-sum game. We prefer to spend our time innovating, rather than drawing lines. True innovation comes from uniting the best parts everyone has to offer.
Steve Millidge, founder and director at Payara, told InfoQ:
As a small challenger company in the MicroProfile and Jakarta EE initiatives, what has surprised me is how open the large companies are in working with our team as equals. Working in MicroProfile and Jakarta EE, by its nature, involves committees, conference calls, and consensus. This can be time consuming and frustrating at times but everybody, from all the companies, is working together to drive forward useful, innovative and consistent APIs for the future.
Working in the Eclipse Foundation means there are good, open-source, rules of engagement and small companies and individuals can join and participate on an equal footing with the big companies. I would encourage any company or individual who has an interest in how the next generation of standards-based Cloud Native APIs evolve to participate. You will be welcome with open arms.
InfoQ also reached out to well-known Java evangelist, Reza Rahman, senior vice president at AxonIQ, to share his experiences from the Java EE Guardians perspective.
To be honest, the strongly collaborative experience in the Java EE community had long been there, at least since I started contributing in the Java EE 5 and Java EE 6 eras. As far as I have seen, the community has always been good about maintaining a professional atmosphere, disagreeing constructively, making sensible compromises and being welcoming to newcomers. Those are the factors that helped give rise to the Guardians when the need became clear.
The big difference now is that Oracle (and Sun before it) does not have the lopsided influence it had for so many years in terms of ownership, road maps, features and delivery. What the MicroProfile community proves out is that the centrally driven influence was really not necessary. The MicroProfile folks also have proven that vendors can collaborate quickly and deliver features faster. The sluggishness that we saw in Java EE in the past really does seem to be a function of Sun/Oracle investment and commitment levels. In addition obviously the open TCK under Jakarta EE is a huge boon.
I am hopeful all of these things bode very well for Jakarta EE if the current patterns under the Eclipse Foundation continue.
Resources
- What Can Reactive Streams Offer Jakarta EE? by James Roper (February 6, 2018)
- In Support of Jakarta EE's Quest to Accelerate Cloud Native Java by Mark Brewer (April 24, 2018)
- Lightbend Podcast: Why Lightbend Joined the Eclipse Foundation's Jakarta EE Working Group by Oliver White (May 7, 2018)
- Latest Roundup of EE4J Activities for Jakarta EE by InfoQ (May 15, 2018)
- Jakarta EE Progress to Date by Mike Milinkovich (May 24, 2018)
- A First Look at Jakarta EE by Roxanne Joncas (May 31, 2018)