Nothing Is Good Enough For Production
When is application server good enough for production? It is one of the most frequently asked questions. The answer is simple and clear: Never.
I tested different application servers for larger deployments and none of them was bug-free. If you dig deep enough, you will always find mission critical bugs.
Also there is a direct relation between the commercial success of application servers and the amount of bugs they have. The more "enterprisy" an application server feels, the less it used by smaller startups and so more challenging use cases. You will very likely find bugs during the realization of more challenging use cases already in the development phase.
The relation between the commercial success and quality of support seems to be inversely proportional. With a large customer base, the vendors are introducing multiple levels of support. If you are lucky the first level support will know what Java is and in best case have a shallow understanding of CLASSPATH :-) (see also the 7 year old post The End Of Commercial Application Java EE 5 Servers). It could take several weeks until you will be able to get your bug approved.
The "smaller" application servers come with an excellent support (sometimes you will get directly the expert or even the committer), but it is less scalable. Also the newcomers are vastly more popular in more interesting projects (e.g. use cases with heavy use of DI, new JPA features, more sophisticated JAX-RS features) and are far better tested by the community.
If you are searching for a "politically correct" answer, choose the big application servers (big download size, long deployments, not freely chosen by developers). If you would like to be productive and have to implement cutting-edge software, choose the "reasonable" application servers (small download sizes, fast deployments, good IDE integration, popular in the community). Whatever you choose, you will have to test a lot. If all your tests are passed--you are ready for production. It doesn't even matter, whether your application server is released or not...
See you at Java EE Workshops at MUC Airport or on demand and in a location very near you: airhacks.io!
...and you should evaluate: Do I even need a JavaEE monster? Scalability can be achieved at a much lower price (in terms of learning curve and complexity). We went from using Glassfish to "just" Tomcat for a large multi tenant eCommerce project and never looked back! I'm not saying that JavaEE is bad or useless. There are just lots of applications which don't need the features provided and where all the JavaEE restrictions limit your possiblities...
Still I love the "cover my ass" attitude - Nobody ever got fired for using Websphere, right? Although it has a questionable perception within the developer community...
Posted by Andreas Haufler on February 24, 2014 at 11:07 AM CET #
they are almost no more JavaEE monsters right now.
Most of the JavaEE restrictions are exactly the same you will find in the most popular cloud platforms. And if you don't like these restrictions and you know what you are doing, you can always violate the restrictions without any consequences.
Btw. I migrated some plain Tomcat projects to GlassFish and the developers were delighted as well. Also I migrated this blog from GlassFish to TomEE and WildFly and it also worked perfectly.
It would be interesting to compare the complexity and footprint of your code to the footprint and complexity of the application deployed on a JavaEE platform.
IMHO JavaEE is the leanest and most productive platform you can currently get :-)
thanks for your comment!,
Posted by Adam Bien on February 24, 2014 at 11:49 AM CET #
Very good article. I would also add one thing. I work for customers who have a very large systems containing old J2EE mixed with the new JEE (core banking or telco systems). They demand that the app server vendor will continue to support older standards and keep growing up with the latest specs. It turns out that you have a "heavy" app server but due to the complexity of their systems and costs the migration from the old J2EE is not an option in the nearest future.
Posted by marek on February 24, 2014 at 06:10 PM CET #
speaking of customers: sometimes the maintainability of the old legacy apps is so low and the cargo cult so high, that moving to a new JavaEE is the only option.
One day you will have to migrate away from Windows XP :-),
thanks for your feedback && cheers
Posted by Adam Bien on February 25, 2014 at 02:57 AM CET #
It would be just so great if finally the community would take over control on Java EE and provide a full EE7 certified, super-fast-startup, highly scalable, and hard as a rock application server! Sad to see that most work in this sector still is driven by commercial vendors.
Posted by Markus KARG on February 25, 2014 at 09:07 AM CET #
I now have decided that CDI (Weld SE) is enough - plug in your HTTP, REST and messaging implementations as you like.
Posted by Juliano Viana on February 25, 2014 at 03:07 PM CET #
Very nice article Adam.
How would you suggest convincing the ivory tower decision makers to leave plain old Tomcat + Spring in favour of JavaEE 6 or 7? I continue to see resistance and scepticism to making the change even today. It seems to me that many developers even within R&D teams deem Java EE6 not a stable enough solution for enterprise development.
For me personally, I never want to work with frameworks again where the core functionality exits in Java EE.
Would love to hear your opinion on the matter. Thanks!
Posted by Jeff Picklyk on February 25, 2014 at 07:13 PM CET #