I was recently pointed to Gartner’s Market Guide to Application Platforms report, written by Anne Thomas and Aasish Gupta. The report takes a very negative view of Java EE to the point that I thought I was reading an obituary. To summarize their report, “Run, Run Away” from Java EE. Hey, if I ever grew up, it was in the 80s. Grab a cup of coffee and sit back, because I have a lot of thoughts to share. If you know me, you’re probably not surprised that this post is approaching (surpassing?) the length of the Gartner report itself 🙂
See it here. OK, OK, I have always wanted to use that clip, but it doesn’t (entirely) apply here 🙂 I will challenge and agree with various points made in the report.
Defining Java Platform, Enterprise Edition (Java EE)
The report takes a very narrow, strict, static, and traditional view of Java EE. BTW, this is something that Java EE developers have not done in a long, long time. Anyway, it’s important for me to define Java EE as background for the remainder of the post.
To be specific, Java EE consists of the following:
- A collection of JSRs, each of which individually define a collection of APIs, a means to test compatibility with those APIs (Technology Compatibility Kit – TCK), and a reference implementation (RI). The RI proves the API is not just an academic exercise and also can be used to clarify nuances that may not be covered in the spec. API implementations need pass the TCK to ensure they are “compatible” with the API.
- Currently, an organization of 33 JSRs under an umbrella Java EE 7 JSR. The specification defines not only the collection of JSRs, but also how they need to integrate and interoperate in a platform context. Java EE implementations must pass the Java EE Compatibility Test Suite (CTS), which – in an oversimplified description – is an aggregation of the “collection of JSR TCKs” that are included in Java EE plus tests that cover additional functionality for working in a platform context.
- A context for which Java EE applications are expected to be developed, managed, and operated. Basically, “roles and responsibilities”. While not explicitly stated in the Java EE JSR, Java EE was originally designed to run in a 3 tier architecture. Note that this bullet doesn’t put a specific requirement on vendors or developers.
Areas of Agreement
There are areas of agreement that I have with the report.
While “choice” is not explicitly called out, the report states that there are options besides Java EE. There is no doubt that the industry is diversifying, driven primarily by the cloud, which in turn is driving the popularity of “cloud native” applications. The cloud is framework agnostic. An agnostic platform leads to choice. I love choice. I want choice. After all, as a standard, Java EE delivers just that, albeit in a different way.
The report recommends that new applications be developed in a “cloud native” manner. I generally agree with this, but “cloud native” is not defined with any detail, only
“They should be built using the mesh app and service architecture (MASA), and be designed with auto-scaling and self-healing capabilities.” I’ve seen customer architecture diagrams that match this very description … using a collection of Java EE monoliths. “Microservices” is what I assume most think of as “cloud native”, but a Monolith can also be cloud native. A monolith can externalize configuration, can be stateless, horizontally scaled, use a service lookup, utilize circuit breakers bulkheads, especially fast-moving monoliths. Self contained systems, which some consider a halfway point between monoliths and microservices, also have these attributes. Regardless, Java EE can be used to develop monoliths, fast moving monoliths, self contained systems, and microservices. Java EE and Cloud Native are compatible. How so? Read On.
Rethinking Existing Application Architecture
I also agree with the report in that 3-tier applications are becoming less and less the “default” architecture. There is a general trend towards cloud native applications / microservices. The cloud offers a whole new set of capabilities that were not there before, like auto-scaling, on-demand application provisioning, etc. The cloud can make organizations a whole lot more efficient if they are able to re-think organizational responsibilities.
I do pick out one or two additional areas of agreement which I’m saving for later. Read on.
Areas of Disagreement
As is probably no surprise, my areas of disagreement with the report outpace my areas of agreement
Move to “Lighter-weight frameworks”
“Lightweight framework” is never defined in the report. It reminds me of the microservices definition, where asking 10 developers will result in 10 different definitions. In some ways it doesn’t matter, because a developer can write a heavyweight application using lightweight frameworks and also write lightweight applications on a heavyweight framework. Sure, Apache Tomcat is lightweight (a consideration Gartner recommends), but you must add weight to it to do anything useful. I’ve seen 500MB+ .war files with a hundred dependencies running on Tomcat with developers claiming it is lightweight. When I see a recommendation to abandon an entire ecosystem for an undefined (or loosely defined “conventional wisdom”) concept, I raise my “high risk” antennae.
Let me address why I think that Java EE is not a “heavyweight framework” from a few perspectives. I’ll begin by separating Java EE the API from Java EE the runtime.
Java EE the API
As mentioned above, Java EE is an aggregation of JSRs which adds up to *thousands* of APIs. Is the number of APIs that make a framework heavyweight? For a vendor to implement, yeah, that’s a lot of work. For a developer, it’s very little work to consume. I need to know zero about the JSF JSR, for example, to expose a RESTful endpoint using the JAX-RS JSR. A developer needs to know enough of the APIs to develop their app. This is no different from the “lightweight frameworks” referred to in the report. A developer doesn’t have to know all of the Spring/DropWizard ecosystem of APIs to develop an application.
What is interesting is that some of the “lighter-weight” frameworks that Gartner recommends heavily leverage JSRs that were created as a part of Java EE (albeit individually defined in their own JSRs). Servlet anyone? JPA? JAX-RS? Does that make those alternative frameworks heavyweight? Obviously not, given the recommendation.
Is it the required availability of 33 frameworks that makes Java EE “not lightweight”? Is it the broad platform aspect of those APIs, where those APIs are designed to work together and must be available to developers that makes them “not lightweight”? I doubt it, since the Spring ecosystem relies heavily thousands of APIs to define a platform.
Returning to the perspective that Java EE was designed with a 3-tier architecture in mind – true. FWIW, 3-tier is still an appropriate architecture for a class of enterprise applications. It’s much simpler than cloud native applications (today) and is well understood by the critical mass of enterprise developers. However, many Java EE developers that have had to create external-facing highly scalable applications have already gone beyond traditional 3-tier towards cloud native using Java EE itself. Those 33 JSRs can be used to write applications using multiple types of application architectures. Java EE has admittedly been a bit behind here in terms of standardizing microservices-specific APIs, but those gaps have been filled by open source and/or homemade frameworks as have been done so many times before. Java EE developers have always mixed Java EE APIs with open source APIs. Something as simple as the Apache Jackson (JSON) API comes to mind since a Java EE JSON Binding API is still in the works.
Now, let’s slice the “platform” and “APIs must be available” points a different way and talk about Java EE runtimes.
Java EE the Runtime
The Gartner report points to the perception of Java EE being heavyweight, while mentioning but not directly tying that claim to Oracle WebLogic and IBM WebSphere. If “heavyweight” implies RAM utilization, startup time, download size, administration complexity, etc, then define the thresholds and where the “lightweight” line is drawn. Instead, it’s a highly subjective point that vendors and developers (and potentially analysts) debate.
Interestingly, some of these metrics have been used to measure “lightweightness” thanks to Antonio Goncalves. I highly recommend that everyone watch his Devoxx Just Enough AppServer presentation, or refer to the cliff notes. Watching it is way better, BTW, but only if you do so after finishing this post 🙂 While I think Antonio’s presentation shows that Java EE is lightweight, it’s still a subjective opinion.
The industry has been changing, and Java EE vendors have recognized this. We recognize that 3-tier architectures are declining in interest. We recognize that deploying multiple applications to a single application server instance are becoming less frequent. We recognize that developers only want to pay for what they use from a resources perspective. We recognize that traditional stateful application server clustering architectures do not map well to the cloud. We recognize the trend to cloud native applications and continuous deployment to achieve agility and speed.
We have recognized a lot, and it’s why Red Hat with WildFly Swarm, IBM with IBM Liberty, Payara with Payara Micro, and Tomitribe with TomEE (the GoF – Gang of Four) have been working hard over the past 5+ years to re-architect our runtimes to better address these recognitions. However, we also recognize that Java EE, from an API perspective, has not kept pace with the cloud native architecture. We, along with the Java EE community, have been addressing these API gaps in different ways, but have also figured out there is a better way. We decided to collaborate in a manner that is very different from the JCP process. Why and how? Errr, sorry, another forward reference. Read On.
Java EE and Manageability
Java EE application servers offer a tremendous amount of functionality above and beyond the required Java EE APIs. A lot of this functionality focuses on manageability, like application and appserver instance lifecycle management, monitoring and metrics, high availability clustering, single point of management, etc. How far down this path Java EE vendors go depends on the vendor. That’s part of the differentiating values and choice customers have.
I suspect that manageability contributes to the “heavyweight” reputation Gartner alludes to. Managing a traditional application server deployment can be complex, but it’s the nature of the problem it has traditionally solved. Within cloud environments, that management complexity is still there, but much more of it is hidden in the cloud. IT operations (for on-premise clouds) have to manage complexity once, and that is leveraged across a number of language platforms running on the cloud. In this sense, Java EE manageability in cloud environments is the same as any other language runtime. How so?
The community has recognized that management functionality is less relevant in the cloud, so have leveraged containers, container orchestration, and cloud management features to compensate. They simply packaged up the standalone (non-clustered/managed) appserver into a docker container image – a one time activity, and layer their applications on that container image. There. Done. You now have a lightweight container. On steroids 🙂 Vendors recognize that traditional Java EE management functionality doesn’t map to a cloud environment very well. To compensate, WildFly Swarm, for example, defers a vast majority of the traditional Java EE management responsibilities to the cloud. Just package the parts of the appserver you need to run a cloud native application along with the app and your done. In Red Hat’s case, we defer management responsibilities to OpenShift (shameless plug requirement – check). Other GoF vendors can also defer management functionality to the cloud.
Java EE and the Standards Process
Another way to parse the “Java EE is not lightweight” claim is due to governance and process overhead to move Java EE forward. 99% of developers don’t care about this point, but 100% are impacted by it. There have definitely been some false starts for Java EE 7 and now Java EE 8. The JCP has served us well in the past. IMHO, Java EE needs to evolve more quickly and the JCP is holding it back because the JCP itself is not evolving quickly enough.
MicroProfile and Optimizing Enterprise Java for a Microservices Architecture.
I agree with the report in that “traditional Java EE” APIs are not optimized for the cloud. While you can surely utilize pure Java EE APIs to create cloud native applications, there has been no consensus on how to go about it. Vendors and the Java EE community were unhappy with the pace of Java EE evolution (errr, it had more-or-less stopped) and its ability to react rapidly to industry changes like the rapid move to cloud native apps. As a result, most vendors and community members were addressing these changes individually. It wasn’t long before we realized that we can do better.
We decided to use an open source approach to collaborate on Microservices APIs using an open source implementation first and then standardize later. By taking an approach that bridges innovation in open source with industry standards, we can move more quickly. So, back in June, vendors and the Java EE community members jointly announced MicroProfile. It’s been moving quickly forward culminating in the most recent announcement – becoming an Eclipse Foundation (Incubator) project. The MicroProfile community is actively discussing and has started working on microservice-y frameworks, like configuration, messaging, circuit breakers, etc.
There is value in choice. One choice, the only choice Gartner is advocating, is to move to a different framework. If you do decide to do that, I’d like to recommend Vert.x (disclosure – I am the Vert.x product manager 🙂 ). Java EE provides its own form of choice by offering customers safety in application portability while leveraging existing knowledge, expertise, processes, and more. Customers may exercise this choice to reduce cost, improve security, as part of a broader ‘stack’ investment, or for specific value-add product features.
My primary issue with the Gartner report is that it seems to completely ignore the advancements that Java EE vendors have made beyond the traditional Java EE APIs and runtimes, nor mention the MicroProfile efforts to develop microservices APIs for traditional Java EE developers. Gartner doesn’t have to agree that these are viable efforts (which would result in a very different blog post 🙂 ), but they should at least inform their customers that there is an alternative being developed that doesn’t require their customers to abandon a healthy percentage of their existing investments and knowledge.
Before you take the high-risk approach recommended by the report by throwing away much of your existing knowledge and investments, please do some actual hands-on investigation with a Java EE runtime that is truly lightweight, focused on cloud native applications, and is MicroProfile compatible. Ahem, like WildFly Swarm (I am Product Manager for that too, not that I’m biased in any way 🙂 )
I also recommend, counter to Gartner’s recommendation, that you consider lift-and-shift of your applications to the cloud … as a first step. Lift and shift first and perhaps make some adjustments in that first step. That will allow you take take advantage of many cloud benefits, like scaling up/down on demand and a common packaging and deployment model, while you decide if you need to (partially or entirely) decompose any existing monoliths into cloud-native applications.
Talk to one of the GoF vendors on how committed we are in helping you bridge the gap from on-premise 3-tier Java EE applications to cloud native applications with Java EE technologies and MicroProfile.
In other words, do your own analysis and come to your own conclusion.