Now that the stack is emerging, it may seem like the future of application servers and application server architectures is bleak. I examine app servers and whether there is any room for them in a modern app development strategy.
Something that you really hear very little about in the press anymore is the notion of an application server, yet it's probably something every enterprise has. Is the day of the application server over?
While I'm not about to proclaim them as dead, app servers are definitely on the wrong side of the growth curve.
App servers gained prominence in the mid-to-late '90s as enterprises moved from client-server architectures to n-tier architectures. Organizations were buying large physical servers from companies such as Sun Microsystems and to maximize the value of their purchase, they needed to move multiple client-server applications onto these servers. This led to what we now know as the application server, with Java EE being the primary example. On the Microsoft side of things, Windows Server was both an operating system and an application server because an operating system has to run multiple applications anyway.
The primary challenge created by app servers was the risk that one application would affect the performance of another application because they were competing for the same resources on the underlying physical server.
Fast forward to today: The deployment architectures have changed dramatically. The underlying hardware has been abstracted away through the use of virtualization and container technologies. Applications have been broken apart into services. Everything we deploy has become smaller, and smaller deployment units mean greater flexibility and fewer dependencies. Why deploy libraries for communicating with a messaging system or distributed transactions if the functional component doesn't need them?
This is the day we live in today. As such, the need for heavyweight application servers with every library you might need is going down. The replacements range from script-based languages (e.g., Python, node.js) and their deploy-as-you-need frameworks, or more lightweight servers or frameworks for Java like Jetty and Spring.io.
So, do you need a traditional application server? You might.
As an enterprise architect, I know that it's increasingly difficult to draw a box around a bunch of components and call it an application. A given approach involves shared databases, shared business services and maybe even shared Web-based APIs. If it were up to me, application would be used only to talk about the UI.
So, the notion of an application server is somewhat dated. At the same time, there are still plenty of situations where things aren't shared, where we're not dealing with Internet-type scalability, and we have a team with significant Java EE experience. Why wouldn't you continue to use your trusted Tomcat or Weblogic server in that situation? Let's also not forget that there are still plenty of third-party applications that require a Java EE server to run.
Just like there are plenty of companies that still have mainframes, 10 years from now there will still be Java EE app servers running in your environment. Although 90% of your activities may be focused on orchestration of the latest Docker-like containers, dynamically moving between the public cloud provider with the best rates and performance for that particular day, you'll still be happy that your Java EE server is running quietly in the background, keeping some of those older, infrequently changing systems doing what they need to do.
Key strategies for adopting container technologies
Check out our advanced Java tutorial