I've noticed a trend where application servers seem to be falling out of favor, and I recently read about Jakarta 11 and Jakarta Data 1.0, which caught my interest. It looks simple to use — you can create a quick app, package it into a small WAR file, and deploy it on an app server without having to run multiple JVMs for each service. For someone like me, running a small Raspberry Pi with a few services, this approach sounds appealing. However, it makes me wonder: why aren't app servers more commonly used today? Is it because Java is seen as mainly a corporate tool, or is the shift towards advanced orchestration methods like Docker and Kubernetes the main reason? I've tried playing around with OpenLiberty and found it straightforward, but I can't shake the feeling that there's something more at play here.
5 Answers
The shift towards containerization is a huge game-changer. The preference now is to deploy everything in a container, making management at scale easier than with traditional app servers. Running a new JVM doesn't add significant memory overhead. For instance, I launched a small webapp with `-Xmx128m` and it used about 95MB without even optimizing. It's not just about the JVM, but how you manage your application code and dependencies.
Thanks for the tip on Javalin! I'll have to try that out.
Running multiple apps in the same JVM can lead to chaos. If one app consumes too much memory, you won't know which app is to blame. From an operational standpoint, it’s much simpler to run one app per JVM to avoid these headaches. This isolation makes managing resources much easier, unlike app servers where you might have to deal with resource leaks and crashes of multiple apps at once.
While I see your point, at the same time, running multiple apps in one JVM has its perks for memory management. But yes, if something goes wrong, tracking the culprit could be a real hassle.
I get that. However, many hobby projects under limited resources can afford the single JVM approach since they're often only handling light loads.
There remains a belief that application servers are too outdated for modern development. They're often ranked as uncool and corporate, which is why many teams avoid them. Instead, they lean towards lightweight frameworks that cater to more streamlined setups. Yet, with Jakarta EE still relevant, there’s potential for growth in newer app server implementations that could bridge that gap and modernize the approach.
Yeah, but isn't the whole idea of Jakarta EE to offer a smoother transition into using app servers? It’s still used by plenty of legacy applications.
True that. It’s just that the tooling has evolved with container orchestration leading the charge, making standard app servers less viable for new projects.
For those using embedded devices or low-RAM scenarios, Quarkus combined with GraalVM native image is a great alternative. It can keep your memory usage per service under 100MB, which is perfect for constrained environments. However, you'll need to get used to longer build times to create those images, but it’s worth the trade-off.
Is 100MB really the norm for Java applications? That seems quite a lot compared to the alternatives.
App servers have definitely been losing traction in business environments due to the increasing popularity of static linking and containerization. Nowadays, bundling your code with all its dependencies into a container is much more viable. It allows for easy reproducibility and minimal setup, whereas, back in the day, managing updates on app servers like Glassfish could be a nightmare, especially when multiple teams were involved. Today, it's all about those light, flexible options.
That's so true! I remember needing to keep binaries small because storage used to be a concern. Now, if a Docker container is 1GB, nobody bats an eye, as long as it runs efficiently.
Absolutely, it makes sense. The JVM can be quite heavyweight compared to other options like Go, which makes app servers seem less appealing these days.
True, but the JVM itself can still be a memory hog when running multiple applications together.