DZone/Java EE Guardians Survey Results: Microservices

As some of you are aware, the Java EE Guardians and DZone jointly conducted a community survey to help determine Java EE 8 features prior to JavaOne 2016. You may also be aware that we shared the results of that survey with Oracle before the details of the renewed Java EE 8 scope was announced. Now is a great time to start analyzing those results a bit more. I’ve already done a high level summary of the results. I’ve also done a deeper dive into the responses for HTTP/2 and Servlet 4, Java SE 8 alignment as well as Java EE security.

Besides asking about relatively straightforward Java EE 8 features, we asked a number of more complex, foundational questions towards the end of the survey. In the prior entry, in this entry and a subsequent few others I am going to take a closer look at some of these questions. I’ll then return back to looking at the more mundane Java EE 8 feature specific questions. It will be clear in a few weeks why this change of order is important at the moment.

The Question
In the prior entry I looked at one of the most fundamental questions we asked – the complex relationship between standards and innovation. If you have not yet read the entry, I think it is a good idea to take a look as vital context to the current entry. In this entry I’ll explore the question we asked about standardizing microservices specific features in Java EE. This is a particularly important question that deserves a very in-depth look. It is certainly a question Oracle, vendors, the community and Java EE’s usual antagonists are paying a lot of attention to so getting this right for everyone is crucial.

Here is how we phrased the question:

“Microservices is a relatively vague term. It can be interpreted to mean decomposing a larger logical application into smaller independently deployable subsystems.

There are frameworks that claim to specialize in microservices and include features such as custom configured, self-contained executable jars (also known as “fat jars” or “uber jars”), metrics, discovery, circuit breakers and bulkheads. Java EE currently does not include such features but it may make sense to add them. It should be noted however that Java EE centric tools such as WildFly Swarm, Payara Micro, WebSphere Liberty and KumuluzEE do offer such features.

Keep in mind, there are some industry thinkers like Martin Fowler that have expressed doubt whether microservices make sense for most applications. Some other folks such as Adam Bien believe Java EE is already well suited to building practical microservices.

How should Java EE approach microservices?”.

The Results
The following graphic shows how the community responded. It’s not realistic to think there would be a simple answer to a pretty complex question, but there are clear patterns. A sizable minority of 44% respondents want Java EE to standardize microservices specific features. The majority 56% however want to wait to standardize or do not want to standardize any further microservices features in Java EE. 27% believe Java EE already has sufficient support for building practical microservices applications. Though not entirely, my personal views most closely resemble this group. I’ll explain myself a bit more later in this writeup. I’ve also explained my views in this screencast. A further 25% believe Java EE should wait to standardize anything more until microservices are better adopted in the practical enterprise. 4% believe microservices is just hype and should simply be ignored.

To put some of this into context, the level of support for standardizing microservices specific features is much weaker than standardizing features such as HTTP/2, more JSON, Java SE 8 alignment, Java EE security and dynamic configuration (some of these items enjoy near 90% support). Indeed the level of support was higher for the Java EE MVC API that has now been decoupled from Java EE and is being led by the community instead of Oracle. The level of support for microservices is essentially in line with standardizing features such as NoSQL and reactive programming.

Digging a little deeper into the data, there is a high degree of correlation between folks that support more microservices features in Java EE right away and folks that equate Java EE to a product instead of an open standard or don’t mind standardizing concepts that would very likely be considered Hype-Driven Development (HDD) by most ordinary developers in the blue collar enterprise (the very readable, extremely unassuming and sensible HDD write-up tellingly includes microservices, NoSQL and reactive programming as prominent examples; if you haven’t done so already, I highly recommend reading the linked article). In effect these folks would not agree with the currently fairly conservative approach to Java EE standardization.

A majority of the people that put in comments essentially had a pretty ambivalent view of adding more microservices features to Java EE right now. Perhaps the folks that have decided to advocate microservices for a few years now without many reservations should pay heed to folks like these? Here is a representative sample of comments:

• “I believe microservices hype will eventually die down”.
• “The hype is already fading. Wait a little and it will be replaced with the ‘next big thing'”.
• “Stop the nonsense with uber jars and let a Java EE server have configurations that let the application define what modules are needed”.
• “The success of Java EE centric tools like WildFly Swarm will dictate the need, or lack thereof, for standardization”.
• “Java EE is well-suited to providing microservices. I am not at all convinced that WildFly Swarm’s approach to service discovery, for example, is something that should be standardized – it makes sense in some use cases, but not others”.
• “I would have picked standardizing fat jars from the first point. The others are just design patterns or good practices”.
• “99% of applications won’t need this. Only very large internet scale companies need microservices. Java EE is mostly used for corporate internal web applications (at least in my experience)”.
• “Although I agree that Java EE already provides the minimum tools to create microservices I think it would be important to make some de-facto guidelines and tools. In particular I think it would be important to have a well-defined standard for self-contained executable jars”.
• “Let the container developers (JBoss, GlassFish, etc) work on this for another couple of years and let it evolve”.
• “WildFly Swarm should be the example to follow, by letting the ‘just enough application server’ idea to settle”.
• “I think the only big challenge is developing a how-to that integrates Java EE with a handful of other technologies to create a microservices architecture which is good enough for everyone else who’s not Netflix”.
• “Much of microservices is hype and is already experiencing some backlash”.
• “For me microservices is an architecture. I think that Java EE as a platform should not be seen as a framework that follows some specific architecture principles”.
• “Let’s wait for MicroProfile and build something upon it”.
• “JBoss like application servers already support modularity, which in many ways make servers lean. A similar kind of standards based approach will help anyone build microservices with their own feature sets enabled”.
• “Microservices are excellent in some cases, but most enterprise systems don’t really need microservices. Combine cloud and application server in the right way and we have microservices in the cloud”.
• “We should just tell developers/architects (or maybe just management) that we’re not all Netflix”.
• “I agree with Martin Fowler that microservices are not already proven and also that they are not required for many applications”.
• “I agree with Adam Bien. Supposedly ‘lightweight’ solutions tend to become heavy over time. I do think it is great to have options so having WildFly Swarm, Payara Micro, etc is a good thing”.
• “Microservices are hype, but can not be neglected. The main driver is actually to get more control of deployment and of configuration for developers. Java should provide mechanisms for that, which would be helpful regardless of whether microservices survives”.
• “I would argue that Java EE fits nicely with microservices as it is today. It is more an architecture choice of style if you find monoliths or microservices a better fit for you”.
• “I agree with Adam Bien that Java EE is already well suited and also with Fowler that microservices may not make sense to most applications”.
• “Application servers with minimum required modules makes sense, but standards are probably not required”.
• “None of the projects I’ve worked on would have benefited from being decomposed into microservices”.
• “Java EE already provides the tools for building microservices. I think it should only create new profiles for microservices which provide the principal JSRs”.
• “Microservices are an architectural pattern, there is no need to standardize it in Java EE”.
• “Java EE should not start to standardize all named features at once but maybe start with uber jars”.
• “Time will bring more understanding and consensus as to what a standard should look like”.
• “Java EE is already great for microservices development. Trust Adam Bien :-)”.

More Microservices Data Points
I don’t think there is any denying the fact that Oracle’s own Java EE 8/9 survey was heavily (perhaps even solely) focused on microservices including the way the questions were phrased as well as the questions themselves (you should judge for yourself: the survey text and results are here). One would expect that support for microservices would be much higher in those results than our survey as a result. I don’t think that is what actually happened. Most of the very microservice specific features such as service health, circuit breakers and modularity/fat-jars ranked below average (that is below 10 amongst 21 items surveyed, in order of importance). Indeed most of the items that ranked above a 4 were pretty mundane items like HTTP/2, REST, JSON, security and configuration. For context, 1 indicated “Not Important” while 5 indicated “Very Important”. Items such a reactive programming, eventual consistency and NoSQL all ranked between 3.5 and 4.

Beyond our and Oracle’s surveys, there is another excellence source of reliable public data we can look at on microservices. The 2016 RebelLabs survey understandably started including questions on microservices. The graphic below shows the results of the survey. Because of the complexity of the question patterns are harder to see but I think it’s safe to say the results are mixed. After a few years of fever pitch hype, only 34% say they have moved to microservices. Of that percentage, only 40% said moving to microservices has had a benefit for them. In terms of total percentages, that’s only 15% of developers realizing a practical benefit from microservices. There are also a troubling data points – 18% of “early” adopters reporting microservices have made life harder for them. Most – 42% – have not seen any real benefit to adopting microservices. Of non-adopters, 32% already say microservices are not for them while another 56% are basically still on the fence.

I think this is hardly the results to thrill the veritable chorus of vendors and “industry thought leaders” unabashedly cheerleading microservices for a while now.

Hype and Reality
The fact that ordinary developers still continue to have mixed feelings about microservices is not a surprise either to me or most folks I know personally in the community. There has been and continues to be a steady stream of people duly warning against the hype. One has to give due credit to Martin Fowler. He was one of the earliest prominent folks to write about microservices but he is also one of the earliest folks to warn about the hype. I don’t think you can get any clearer about what is going on than saying “enough to get everyone’s over-hyped-bulls*#% detector up and flashing” or “the majority of software systems should be built as a single monolithic application”. There have even been some pretty brave folks on the vendor side on the equation. Ruby on Rails creator David Heinemeier Hansson wrote an excellent blog entry titled “The Majestic Monolith” that is well worth reading for all server-side developers. My friend and fellow Java EE enthusiast Adam Bien has even gone as far as to making a fairly bold prediction of a backlash against microservices and uber jars as soon as this year. There is plenty more around once you begin looking including some humorous but pretty insightful memes from ordinary folks.

It is safe to say like these folks, I don’t mind being called a microservices skeptic. While I’m sure it doesn’t help our egos much, I don’t think most companies have the same problems as Netflix, Amazon or Google (and yes, that includes most Fortune 500s). For the vast majority of applications out there, microservices seriously violate the YAGNI principle – the associated costs and complexities are just not worth it and never will be. My general rule of thumb for considering microservices for most real world projects is a team size of about 7-10 active developers.

For projects that can actually benefit from microservices, the “micro” part of microservices still violates the YAGNI principle. Indeed what makes sense is breaking these systems down into pretty sizable sub-systems with distinct sets of business users. An example would be a larger insurance system that is broken down into point-of-sale, data capture, underwriting, policy management, payments, customer service, reporting, archival, etc sub-systems. The reality is that many of us have been successfully developing both these types of “microservices” applications in addition to monolithic applications with vanilla Java EE for a long time now.

This pragmatic approach is far away from the CORBA-like remote objects most microservices proponents seem to have an infatuation with where you would see dozens if not hundreds of distributed remote services comprising an application like account service, product service, user service or order service. There are only a tiny handful of companies that actually benefit from this level of granularity. These are the types of applications that really need the features that are offered by products like WildFly Swarm or KumuluzEE beyond what vanilla Java EE already offers. I’ve explained all of this in a fair amount of detail beyond what I have the space to say here in the screencast I referenced earlier in this entry.

What Should be Done in Java EE?
Whatever the right thing to do in Java EE is, Java EE vendors should not let microservices hype pass them by. They should absolutely make sure their Java EE centric products are microservices “buzzword compliant”. Part of the issue is that it will take a while for pseudo-technical people in IT decision making roles that nonetheless hold CIO, CTO, architect and development manager titles (some of us lovingly call these people “PowerPoint Architects”; I’m sure you know the type) to be able to separate the hype vs. reality of microservices. Some may only learn the hard way by experiencing project failures, cost overruns and maintenance headaches themselves. We have to be honest with the fact that Java EE is not completely immune from the need for buzzword compliance either. That said if Java EE capitulates every time the hype of the day came along, it would quickly lose it’s well-recognized core value proposition as a stable, backwards-compatible open standard that serves as a buffer against hype and minimalist core for broad ecosystem innovation (indeed this is precisely what went wrong in the J2EE era).

I really don’t think most of the features that Oracle is proposing for Java EE 9 really should be standardized yet. This includes things like dynamic discovery, metrics, circuit breakers, client-side load-balancing, eventual consistency and so on. Just as is the case with WildFly Swarm and KumuluzEE, at this stage vendors should be actively innovating with and building on top of Java EE for these sorts of features. Collaboration on microservices features through open source initiatives like MicroProfile is also an extremely good thing. This approach allows for the usability and applicability of these features to be much better understood and allows ample space for the ecosystem to fully innovate before any standardization takes place. Maintaining a product-first approach also means these features get to developers faster, as they need to meet (real or imagined) needs. Mutual collaboration through MicroProfile also allows for rapid standardization later when the time is right. On the other hand, if the microservices ambivalence now in conference talks like “Microservices for Mere Mortals” and “The Dark Side of Microservices” turns into a full-scale grassroots backlash down the road, these features need never be standardized in Java EE. I’d say the biggest problem now is that Oracle is not part of MicroProfile and does not have an open, collaborative microservices product plan outside of what they said they wish to do in Java EE 9.

None of the above means there aren’t features that shouldn’t be moved forward in the core open standard. There are plenty of more straightforward Java EE features that I think would be welcomed well by the community:

• Features like dynamic configuration and OAuth/OpenID support have been relatively well-awaited, are reasonably well-understood would be useful for projects whether they are using microservices or not.  Oracle initially considered these features for Java EE 8 but then appears to have deferred these features to Java EE 9 in order to deliver Java EE 8 faster (a welcome move).
• Considerations to fully modularize the platform has been around since the Java EE 6 timeframe. The big practical hurdle to doing this was the fact that Java did not have a built-in module system. I have to be honest in that I think modularity is a bit of a Red Herring overused in the usual anti-Java EE rhetoric. I’ll write more about this in a slightly different context in the next few weeks but I don’t think modularizing Java EE is a practical issue when the average Web Profile implementation is 35-50 MB and the average full profile modern Java EE application server is 120-150 MB. Let’s remember that the commodity disk space these days is approaching the terabyte range and an average network speed of over 10 mpbs is really not that uncommon anymore (I do have to admit there continue to remain real disk size offenders such as WebLogic at 800 MB – 1.5 GB). That all said, Java SE 9 modularity makes modularizing Java EE along the lines of it’s already separated constituent JSRs a real possibility and something that would be welcomed by many. This feature does have a real use case in very resource constrained embedded systems/IoT use cases. Indeed much of this has been possible in modular application servers like GlassFish since the Java EE 6 time frame.
• To go along with modularity, it would be useful to have additional profiles in Java EE. For example a very minimal Servlet-only “Core Profile” and a “Microservices Profile” targeting a simple, non-persistent but JSON-capable REST endpoint certainly makes sense. This is very similar to what was done with Java SE 8 Compact Profiles.
• Similar to modularity, I don’t think fat-jars are as cut-and-dry as most people seem to think. In fact I think Adam Bien might be right that fat jars can prove to be an actual anti-pattern with Docker compared to Java EE thin war files with time. That said, embeddable containers have been advocated for a long time in the Java EE expert group. I do think standardizing fat jars would be welcome by many in the community. Again, most application servers other than WebLogic already have this capability now. They do have a legitimate use case when working with bare metal JVM based PaaS environments that make a separate server installation difficult.

Going forward, the positions in this section is what I plan to personally advocate in the Java EE expert group. That said, there is always ample room for learning more in our ever volatile industry and perhaps my views will evolve over time as things continue to move forward.

I do hope this post serves as food for thought in the complex topic of Java EE and microservices. Please do stay tuned as I further look at topics in the survey. In addition to my write-up, I would encourage you to look at the survey results yourself and get involved in Java EE. You can certainly do so by becoming a part of the Java EE Guardians.