Last week we looked at the release of MicroProfile 1.0. This week we take a more in-depth look at how the MicroProfile initiative came about. We talked to Mark Little, Lead of JBoss Technical Direction and Research/Development and John Clingan, Senior Principal Product Manager at Red Hat about the benefits to all involved.
History of MicroProfile
In the difficult times before this year’s JavaOne announcement of an ambitious roadmap for Java EE there was a void. This was in part filled by the Java EE Guardians, and in part inspired a more serious look at the MicroProfile standard. This is not a competing standard to Java EE, but attempt to feed the standards. It is a collaboration between Red Hat, IBM, Tomitribe, Payara, the London Java Community and more.
In the standard space, a smaller profile was originally discussed for inclusion in Java EE 6. It was debated whether there should be an embedded version of EE, something that bootstrapped from the public static void main. The conversation came up because in Java EE 6, an embeddable EJB Container API was being added. Should something be created for the whole platform?
According to David Blevins, Founder of Tomitribe in the vJUG24 panel on the 27th September, the consensus was that they were not ready to standardise, and not in Java EE 7 either. There were not enough people with experience in that space to progress it.
“Once you make a choice, you have to live with it for 10-20 years. …When standards make a guess, you get things like CMP. When they standardise something based on maturity, you get JPA.”
Innovation over standarisation
Rather than attempting to start with a standard, MicroProfile is a place for pre-standard exploration. It doesn’t claim to have the answers, and has started with a conservative list of technologies (JAX-RS, CDI and JSON-P). The idea is to give the community the opportunity to define what it should become. In the meantime it will have a short release cycle for faster iterations and faster learning.
Taken from the MicroProfile Presentation slide deck.
Oracle have been invited to participate, and MicroProfile plans to become part of the Eclipse Foundation using the Apache license. This will allow it to continue to be community led and vendor neutral. It will also allow for different parties to dip in and out according to capabilities. Once the support of the Foundation is in place, they can look at submitting JSRs into the Java Community Process.
Ask the experts
Voxxed caught up with Mark Little and John Clingan of Red Hat for a more in-depth discussion of MicroProfile.
MicroProfile 1.0 is designed to be vendor-agnostic: what are the particular benefits/ motivations for companies such as Red Hat in contributing?
Mark Little: It’s the usual benefits of working in open source: collaboration creates best of breed efforts. We can share our experiences, figure out what works based on input from others and having early feedback from users on our thoughts and implementations.
John Clingan: Many traditional Java EE vendors recognized a while ago that that we needed to adjust our implementations to work better with modern applications. Java EE only defines APIs, not implementations. WildFly Swarm, IBM Liberty Profile, Payara Micro, TomEE, and Hammock.io are examples of how vendors are adjusting implementations to better address modern development and deployment practices. That’s great in that there is a tremendous amount of innovation happening around microservices and Java EE. However, it also “splits” the Java EE community by developers having to focus on one particular implementation. MicroProfile gives developers a single place to go for collaborating on Java EE microservices with vendors. Developers will then benefit from choice of implementation.
Where do you see the MicroProfile platform definition providing the most use – what types of applications will benefit the most from this?
Mark Little: We see and hear a lot from other vendors and communities around microservices and greenfield development, i.e., where you have the ability to start from scratch. Whilst that is definitely an important area of development, the majority of microservice developers are working in so called brownfield areas. There they have significant investment in existing software. Java EE is the dominant enterprise middleware solution out there. Therefore it’s inevitable that people want to understand how they can pull apart their Java EE applications into microservices or even start from scratch with Java EE and build microservices. That’s where MicroProfile really comes into its own.
John Clingan: Well said, Mark. Organizations want to leverage as much of their existing skills and infrastructure as possible.
There are talks about adding support for asynchronous reactive event processing and big data – how will it be implemented in a way that retains the lightweight nature of the platform?
Mark Little: The honest answer is that at the moment we don’t know! We haven’t begun those discussions in earnest yet. However, we all understand that adding asynchronous, reactive events into the system will require more than just asynchronous HTTP or asynchronous JAX-RS support. There are some significant issues with existing Java EE specifications which have always been developed assuming a synchronous pattern. So potentially we have to look at everything in the Java EE umbrella. Fortunately given that we are starting from a very minimal series of specifications with MicroProfile 1.0, we can start small there too and build up.
From a Red Hat perspective, we have a lot of experience here with the Vert.x project. Our two teams (Vert.x and WildFly Swarm) are working closely together to figure out how these things can best be integrated for the benefit of developers. As we move forward, I’d expect those discussions to move more to the MicroProfile project so we can share them with others and hear their experiences and feedback.
What libraries and frameworks can we expect in the future?
Mark Little: We just published our recent survey on the MicroProfile.io site. Whilst we aren’t necessarily committing to following that survey exactly, take a look as it will influence our direction.
John Clingan: Exactly. MicroProfile is not intended to be vendor-led, neither by a single vendors nor by a collection of vendors. We intentionally started with a very small feature set to let the community define its direction. It’s also why we announced our intention to move MicroProfile to the Eclipse Foundation. Below is a possible set of features. Note the asterisk. These are not prioritized (yet) nor are all features guaranteed to be delivered. This will all be figured out in the community.
Taken from the MicroProfile Presentation slide deck.
What features would you most like to see in MicroProfile 2.0?
Mark Little: Async, reactive. Definitely security (we discussed that at the JavaOne MicroProfile BOF). A binary messaging protocol – HTTP isn’t really sufficient for microservices at scale.
John Clingan: I suspect we’ll have a few incremental releases first [1.1, 1.2] until we get the release train model going. My hopes are inherent support for microservice patterns – Circuit breaker, bulkhead and, yes, security. In fact, it was great that Phil Webb from Pivotal attended the BOF. We expanded the idea of interoperability beyond just MicroProfile implementations to external platforms as well like Spring Boot and Node.js. The initial example was JWT security token exchange.
What are your hopes for the future of MicroProfile and Wildfly Swarm?
Mark Little: I hope it’ll continue as a bidirectional effort, i.e., Swarm influences MicroProfile and vice versa.
John Clingan: In addition, to accelerate the adoption of Enterprise Java in general as a microservices platform and give Red Hat customers a low-risk path forward by leveraging their Java EE skills and JBoss EAP investments.
How you can help
You can join the discussion on the MircoProfile forum, see examples on GitHub and information about individual implementations here.
The post MicroProfile in depth appeared first on Voxxed.