The Tribe Blog

MicroProfile: Optimizing Enterprise Java for a Microservices architecture

3161
No Comments

Today we are announcing a new collaboration called the MicroProfile.  Together with Red Hat, IBM, Payara, the LJC and all who will join us, we aim to merge innovation and standardization into Enterprise Java with Microservices focus.

MicroProfile

Microservices in Enterprise Java

If you look at all the servers in the Enterprise Java space, particularly Java EE implementations, you see a trend: lighter is better.  From the day TomEE was announced in 2011 it was a 30MB distro, 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.

We were convinced then the future was going to be different.  In the very first interview on Apache TomEE in 2011 with O’Reilly Media, I vividly recall one statement we made which concluded the interview:

We’re trying to redefine enterprise as small.  People usually think of enterprise as big.  But in today’s age the real secret sauce to the enterprise is small, a lot of small… hundreds of small.

You can see the foreshadowing of the Microservices movement brewing in that statement.

Today all of us vendors in the Enterprise Java space are focused on “small” and solving problems in a Microservice world such as security, metrics, monitoring, orchestration, uber-jars, booting in seconds and more.  We have, however, been doing it independently, which is what makes the MicroProfile so compelling and necessary.

As of now, we will be exploring the innovative edge together.

Standards and the Innovative Edge

If I were to describe the relationship between standards and innovation I might describe it as follows:

  • Innovation is trailblazing, machete in hand, forging new paths and looking for new destinations

  • Standardization is paving the paths most traveled with concrete, allowing mass transit, gas stations, hotels and a true multi-vendor city to exist.

While some may criticize the need for standards, trading them instead for speed, there’s no denying that most single-vendor cities crumble in the long run.

Few things can touch the empire standards have built in Enterprise Java over the last 20 years

This unfortunate tradeoff of standards for speed is a key thing the MicroProfile aims to address.  With the MicroProfile we aim to include the community, compare our offerings, find commonality and use our collective tools and use cases to rapidly explore the edges of the microservices space.  What makes it different than a standards process is timing; we’re coming together to collaborate at the innovative edge to explore ideas, prove them out and feed the standardization process with the best of the best when the time is right.  This is not the act of cementing, but the act of trailblazing.

The benefits are simple: we and those who trailblaze with us are committed to future standardization; those who follow are on the path to a multi-vendor city that won’t crumble or become too expensive to live in over time.

Performance, Metrics and Security

Initial technical goals of the MicroProfile are likely to stay extremely focused along what is already common between the participants in efforts to get something to market as soon as possible.  However, we all have our wish-list of long-term areas of focus we’d like to see the MicroProfile bring the industry.

Performance Guarantees

While standards in the Enterprise Java space do a great job of specifying what APIs must be included, we’ve historically never made any requirements on the size and speed of the resulting implementation.  It’s quite clear this is a key aspect of Microservices and is actually being met by all Enterprise Java implementations in the market.

It’s time we consider making it an official requirement.  Apps should start in seconds, memory usage should be small, distribution size should be equally small.

Common infrastructure has prevented these kinds of requirements from being realistic in the past, however with the plethora of IaaS choices and cheap ARM devices like Raspberry PIs, such a requirement is within reach.

Metrics Gathering

When there are hundreds of Microservices buzzing about in an enterprise, visibility is key.  There are ample tools out there to mine data out of app servers for the purposes of aggregation, visualization, monitoring and tracing.  The trick, however, is these tools are forced to mine that data themselves.  They must become experts at the bytecode level of every app server from which they want to mine data.

This needlessly expensive, and inherently troubled, approach is only necessary because there are no standards on what kind of metrics data should come out of an app server or container.

We are overdue for standards in this space and the existence of them would allow tool vendors in the Monitoring/Visualization space to focus on telling elaborate stories with our data instead doing our work for us mining this data from our platforms.

Security Interoperability

When apps are monoliths and shared state is visible to a large number of apps running in the same large server, stateful security architectures are less of a concern.  As we shift to a Microservices world which is extremely decentralized, using the same stateful security techniques poses a very significant problem.  Using stateless security with things like OAuth 2 and JWT to propagate state don’t just become a good idea, but an absolute necessity.  Combined with approaches for message signing such as HTTP Signatures and you have an incredible powerful microservices-friendly security architecture where blind trust or whitelisting does not exist.

While all these specs exist, their overly flexible definitions make any chance for interoperability impossible in micro-hops between Microservices.

A future direction for the MicroProfile could contain more exact definitions on how these concepts must be implemented with a Microservice mindset, allowing for security interoperability between applications leveraging the MicroProfile.

Give your feedback

While there are many things we’d like to see, the most important opinion is yours.  There is a survey on the main page of microprofile.io.  Please take it and help steer the effort.  Your feedback is critical to the innovative process.

As well, participation is open to any community, company, group or individual.  Get involved by joining the mailing list, submit that idea you’ve been working on (you know you have one) and help take Enterprise Java and Microservices to the next level!


Tomitribe CEO

About the author

David Blevins

Founder & Chief Executive Officer
Follow David Blevins
Prior to founding Tomitribe, David’s extensive experience creating meaningful relationships between business and Open Source includes 7 years at IBM rebranding Apache Geronimo as WebSphere CE, technical leadership in Gluecode (acquired by IBM), and a key role in Apple’s integration and distribution of OpenEJB in WebObjects. David is a co-founder to OpenEJB (1999), Apache Geronimo (2003) and Apache TomEE (2011), 10-year member of the JCP serving in Java EE, EJB, CDI, JMS and Java EE Security JSRs, JavaOne RockStar for 2012 & 2013, 2015 inductee into the Java Champions and nominated for JCP Member of the Year 2015. He is a contributing author to Component-Based Software Engineering: "Putting the Pieces Together," from Addison Wesley and a regular speaker at JavaOne, Devoxx, ApacheCon, OSCon, JAX and Java-focused conferences.