(It seems my middle name has become “War and Peace“)
This was my 18th JavaOne, and was the most enjoyable of all because it was the first one where I had no work obligations – I was an attendee. Yeee Haaaawww!! So, what was I doing at JavaOne? I was scoping out Java EE and microservices. While Java EE competitors wish it to be so, Java EE is not dead. Java EE is evolving.
Microservices, yes, it’s among the newest of the “My presentation is likely to get accepted” hype-words, but as a product manager I need to see how others – developers, customers, and vendors – define and approach the topic. Hype words do have some meat behind them. Microservices, for example, is by-and-large a different way of architecting Java EE applications compared to how we did them 5-10 years ago (let’s stay away from SOA for now, shall we?). So how does Java EE gel with microservices?
First, let’s define microservices. Here’s Red Hat’s definition:
An architectural approach, that emphasizes the decomposition of applications into single purpose, loosely coupled services managed by cross-functional teams, for delivering and maintaining complex software systems with the velocity and quality required by today’s digital business.
Here’s how I position Java EE and microservices in a WildFly Swarm slide:
There is context around this slide in the broader “deck”, but hopefully you get the point. Java EE, broadly defined, is a collection of API specifications. How those APIs are implemented and, more importantly in this case, how they are assembled into a runtime is up implementations. What is great about this approach is that vendors innovate and customers get choice.
I won’t dig into details, but I saw WildFly Swarm, Payara Micro, and Tom EE all demonstrated very lightweight approaches to running “microservices” with Java EE at JavaOne. It’s overly simplified and somewhat incorrect to say that a microservices is “just enough app” and Java EE runtimes are delivering “just enough appserver”. A microservice is not really an application and Java EE runtimes as “fat jars” are not quite appservers. However, I find it the best one-liner combination to bring the two worlds together. I’m open to better one liners, or you can pound me into submission with a multi-liner What is important to note is that in this case there are three implementations to choose from, none of which force the developer re-write their code when moving between them. Well, except the pom.xml file. This is the value of Java EE.
The interesting question for customers becomes “what do I do with all of those existing ‘monolithic’ Java EE applications that I have?” Well, the best answer is “if it’s not broke, don’t try to fix it”. Monoliths have their place in application architecture. However, if particular applications are too rigid for the business, whether it be due to scaling just specific functionality or rapid versioning to introduce new functionality, then you can begin to think of decomposing an existing application. The simplest way of introducing microservices is by developing new functionality as microservices and using existing distrituted computing APIs like JMS and JAX-RS to leverage to the monolith. This is a multi-post topic in and of itself.
I’ll end it here for now, but I’d love to see your comments on Java EE and microservices. Coming soon I’ll talk about other stacks, like vert.x and node.js.
P.S. Hat tip to Rich Sharples for “Just enough Appserver”.