JEE in the cloud era: building application servers
Nothing riles up the passions of the developer community more than pointing out that a technology is dead. Much to my surprise, Java Enterprise Edition still has fans loyal enough to get riled up . JEE as a specification may not be dead but bloated JEE application servers most certainly are and have been for well over a decade.
About ten years ago I was working at a major Wall Street firm. The platform we were using for the trading system was JEE. The application was deployed as an EAR archive to a BEA (at the time) WebLogic server. Each developer needed to run an instance of WebLogic on their workstation. Each application ran on its own WebLogic instance. The teams had dedicated developer, QA and Production servers. The environment was ripe for a license audit.
In a project status meeting our managing director asked us to take an inventory of the WebLogic licenses we were using and what for. We were to get back to him with a number and the cost of licenses we needed to keep the project going. I was tasked with figuring that out.
Instead, I went back to the manager and pointed out that our application was using only a small subset of the services WebLogic offered. Each of those services could be easily substituted with an open-source alternative. I estimated a two week effort by a single developer to surgically remove WebLogic from the application code base.
My idea was well received and was low risk enough that the manager was willing to let me prove it to him. A couple of weeks later I came back to him with a demo. The JEE and WebLogic based server backend of the trading system was replaced with a lightweight Spring and Jetty based API backend. We gained power to customize and improve redundancy and fault tolerance to our exact specification. Finally, the team realized the improved productivity and faster turnaround time.
Ever since, my advice to IT managers has been to lose the JEE server bloat. When I joined Liquid Analytics we’ve done the same: streamlined our services infrastructure for the cloud era without relying on a bloated JEE server.
Eberhard Wolff wrote an excellent two-part post on why Java application servers are dead that covers all major points. I’ve never been a fan of Java application servers. As an intern at IBM in the mid 1990s I convinced my manager to bypass IBM’s own WebSphere for lack of a good technical reason to use it. Operating systems do a much better job hosting applications than application servers can. The application server feature bloat always seemed to me as a way for enterprise software vendors to convince IT management to spend exorbitant amount of money on unnecessary middleware.
Enterprise application server vendors are able to get away with highway robbery only because most developers and IT management lack understanding of what application servers actually do. Rather than repeating what Eberhard Wolff wrote on the topic, I would like to focus not on what they do but what applications actually need.
Web applications require some sort of a server where they can be hosted and delivered. Some mechanism is needed to serve both static and dynamic content as well as to host REST API.
As the application gets bigger it becomes more difficult to manage its bootstrap and initialization code, as well as to maintain reusable components.
Relational databases require connection pooling as a way to control resource utilization and security. That, in and of itself deserves its own article.
In many situations the application needs some sort of a distributed messaging protocol. Good use cases include push notifications in a distributed environment, and persistent message queues.
Most applications do not need an RPC (Remote Procedure Call) mechanism. In a large backend ecosystem, however, there is a justifiable need for some sort of an RPC mechanism among various modules.
Sooner or later any application worth its number of lines of code is going to need some sort of a task scheduling mechanism.
One of the things that JEE servers offer is a deployment workflow for applications. In many JEE implementations, an application can be deployed in a rolling fashion with minimal disruptions to end users.
All applications need to be monitored. Commercial JEE servers offer health checks and integration with SNMP and other enterprise monitoring tools.
The value of the application server is in bundling of these services so that the developer does not have to think about gluing them together. In upcoming posts, we will explore ways of obtaining the necessary services without dealing with the JEE server bloat, so stay tuned.
Photo by Scott Beale / Laughing Squid
Some background
About ten years ago I was working at a major Wall Street firm. The platform we were using for the trading system was JEE. The application was deployed as an EAR archive to a BEA (at the time) WebLogic server. Each developer needed to run an instance of WebLogic on their workstation. Each application ran on its own WebLogic instance. The teams had dedicated developer, QA and Production servers. The environment was ripe for a license audit.
In a project status meeting our managing director asked us to take an inventory of the WebLogic licenses we were using and what for. We were to get back to him with a number and the cost of licenses we needed to keep the project going. I was tasked with figuring that out.
Instead, I went back to the manager and pointed out that our application was using only a small subset of the services WebLogic offered. Each of those services could be easily substituted with an open-source alternative. I estimated a two week effort by a single developer to surgically remove WebLogic from the application code base.
My idea was well received and was low risk enough that the manager was willing to let me prove it to him. A couple of weeks later I came back to him with a demo. The JEE and WebLogic based server backend of the trading system was replaced with a lightweight Spring and Jetty based API backend. We gained power to customize and improve redundancy and fault tolerance to our exact specification. Finally, the team realized the improved productivity and faster turnaround time.
Ever since, my advice to IT managers has been to lose the JEE server bloat. When I joined Liquid Analytics we’ve done the same: streamlined our services infrastructure for the cloud era without relying on a bloated JEE server.
Eberhard Wolff wrote an excellent two-part post on why Java application servers are dead that covers all major points. I’ve never been a fan of Java application servers. As an intern at IBM in the mid 1990s I convinced my manager to bypass IBM’s own WebSphere for lack of a good technical reason to use it. Operating systems do a much better job hosting applications than application servers can. The application server feature bloat always seemed to me as a way for enterprise software vendors to convince IT management to spend exorbitant amount of money on unnecessary middleware.
What are JEE application servers for ?
Enterprise application server vendors are able to get away with highway robbery only because most developers and IT management lack understanding of what application servers actually do. Rather than repeating what Eberhard Wolff wrote on the topic, I would like to focus not on what they do but what applications actually need.
Static and dynamic content and REST API
Web applications require some sort of a server where they can be hosted and delivered. Some mechanism is needed to serve both static and dynamic content as well as to host REST API.
Component management, dependency injection, inversion of control
As the application gets bigger it becomes more difficult to manage its bootstrap and initialization code, as well as to maintain reusable components.
Database connection pooling
Relational databases require connection pooling as a way to control resource utilization and security. That, in and of itself deserves its own article.
Distributed messaging
In many situations the application needs some sort of a distributed messaging protocol. Good use cases include push notifications in a distributed environment, and persistent message queues.
RPC protocol for microservices
Most applications do not need an RPC (Remote Procedure Call) mechanism. In a large backend ecosystem, however, there is a justifiable need for some sort of an RPC mechanism among various modules.
Task scheduling
Sooner or later any application worth its number of lines of code is going to need some sort of a task scheduling mechanism.
Deployment, upgrades, and versioning
One of the things that JEE servers offer is a deployment workflow for applications. In many JEE implementations, an application can be deployed in a rolling fashion with minimal disruptions to end users.
Logging and monitoring
All applications need to be monitored. Commercial JEE servers offer health checks and integration with SNMP and other enterprise monitoring tools.
Stay tuned
The value of the application server is in bundling of these services so that the developer does not have to think about gluing them together. In upcoming posts, we will explore ways of obtaining the necessary services without dealing with the JEE server bloat, so stay tuned.
Photo by Scott Beale / Laughing Squid