Rick Sharples: Why pay for a Java EE application server?

Discussions

News: Rick Sharples: Why pay for a Java EE application server?

  1. Rick Sharples, a Sun engineer, responded to a Javalobby post with "Why pay for a Java EE application server?," saying that "free" wasn't the end of the story: features, performance, support factor in as well.

    The original Javalobby post had this text:
    JBoss is a J2EE app server with a good reputation and it's free. The same holds true for Resin. So why Fortune 500 companies pay for super expensive app server's licenses and purchase WebLogic or Websphere? Are they just plain stupid or there is something else that it's not obvious for a regular J2EE developer?
    Disregarding the obvious slant and emotion of the original post, Mr. Sharples' reply had some good points, but was itself merely a starting point for discussion itself, because he finishes with a huge product plug for Sun's application server without quite acknowledging that the free application servers also have specific features, performance, and support networks.
     
    What do you think? What is the justification for using the application server (if any) that you use? Is that justification enough to make you decide the same thing in the future? What criteria should an application server have?

    Threaded Messages (22)

  2. 6 words ...[ Go to top ]

    "You get what you pay for."

    I think that about sums it up. Open source is great (I use it all the time), but some open-source hippies seem to be in denial about the quality of open source in general (just my opinion). I'm speaking very generally here. Honestly, how many open source web site have you been too that produce comprehensive documenation, samples, and support ... in a timely manner?!? I take part in many open source projects and my experience has been that you're more or less on your own unless some other user takes pity on you and throws you some nugget of support. Commericial apps are here to stay. Just my 2 cents.
  3. 6 words ...[ Go to top ]

    Well, the irony here is that "you get what you pay for" works both for and against Rick here, as Sun's app server is "free" as in "cost" - just like JBoss is, with Sun and JBoss both offering support services.
  4. is it really free?[ Go to top ]

    To me, JBoss isn`t free. Last time I worked with it there was no useable documentation, even if you pay for it. Whole subsections of the (purchased) documentation would contain only a single incomplete sentence. JBoss consulting isn't cheap and if they have an similarity to the personality of Fluery, I`d probably beat the crap out of the consultant before I got my money`s worth.
  5. 6 words ...[ Go to top ]

    For the most part I agree with that sentiment but the truth is a little more dodgey when it comes to app servers. I have used WebLogic extensively and the companies that were paying for it payed dearly for those licenses. However, I found their product to be buggy, well documented in some areas and very poorly in others, and the support dismal (getting anything actually resolved always requires going through escalation procedures). Their EJB caching in the 7.x product was completely broken. I've heard, even after they rewrote it for 8.x, that it's still broken (have fun using it in a cluster). Granted, I'm talking about one vendor here. I haven't used WebSphere or any of the other ones. But my point is that just because you pay a bunch of money doesn't mean that you're getting what you pay for.

    I think it's really a testament to the state of app servers that you see this situation.

    And before anyone thinks I'm some kind of open source junkie...I spend far more of my own money on tools than anybody else I know.
  6. The real costs of application servers[ Go to top ]

    Take a junior JEE developer that is new to application servers and have them install Weblogic and JBoss. Have them configure it with DataSources and JMS. Next create a simple EAR containing Session EJBs, Message EJBs and a basic web service. The time it takes from start to finish + licensing costs is the real cost of software.

    For someone like me that has been working in JEE since it's enception, JBoss is the least costly. But for the beginners, JBoss is unwieldy and complicated. Will this change in the future? Yes. JBoss will become increasingly easier to use. Just like Hibernate, Struts, and JSF is easier to program with Eclipse plug-ins from Exedel and MyEclipse.

    John Murray
    Sobetech
  7. nog een testje
  8. the previous was a test since i posted several times without result. Lost my original text, don't want to type it again sorry, it was a rant anyway.
  9. Since my appserver is hanging again i have time to rant about it. That thing makes my daily life a nightmare. The bigger companies are like sheep, they follow eachother. For some reason the first one bought the story and now we are all doomed. Why pay for a server?

    - because of support, never had it.
    - extra features, another phrase for "lock in".
    - quality, my ***.
  10. John,

    I wouldn't agree with you. I'm just a student and not a junior JEE developer. We had to do a small EJB project in our university and therefore we had to use WebSphere for this kind of project. After we tried WebSphere several times without success we decided to use JBoss. It was very easy to set up and to use. The documentation for us as beginners was very good what was actually surprising for us.

    Thomas
  11. Seems more and more the question is why use a JEE application server at all.

    Or rather, how often do you really need something bigger than a Servlet container?
  12. Seems more and more the question is why use a JEE application server at all. Or rather, how often do you really need something bigger than a Servlet container?

    +1!
  13. As soon as you need horizontal scalability, or true asynchronous operations, or distributed transactions and processes... not that you can't get those with just a servlet engine, but it's a lot more work than using JEE at that point.
  14. As soon as you need horizontal scalability

    Do you mean clustering here?
    or true asynchronous operations

    JMS isn't enough?
    or distributed transactions and processes

    An XA JDBC driver and JTA isn't enough?
    not that you can't get those with just a servlet engine, but it's a lot more work than using JEE at that point.

    I think you can get enough of it with Spring and a servlet engine to get by in a lot of cases.

    %
  15. not that you can't get those with just a servlet engine, but it's a lot more work than using JEE at that point.
    I think you can get enough of it with Spring and a servlet engine to get by in a lot of cases.%

    Since when Spring provides JTA Transaction Manager implementation for 2PC transactions support? Or may be any servlet container has it? Not the last time I checked. What you going to do if you need one? How about try JOTM without transaction recovery code implemented, or JBoss without persistent transaction log? Have a productive day.
  16. or true asynchronous operations
    JMS isn't enough?
    JMS is enough, but it's not part of the Servlet spec, and plain Servlet containers don't provide JMS.
    or distributed transactions and processes
    An XA JDBC driver and JTA isn't enough?
    No, you also need a transaction manager. Again, Servlet containers don't usually come with a JTS XA transaction manager.
    not that you can't get those with just a servlet engine, but it's a lot more work than using JEE at that point.
    I think you can get enough of it with Spring and a servlet engine to get by in a lot of cases.%

    Spring USES these services (JMS and JTA) but doesn't PROVIDE them. You'll need to integrate other libraries / servers into your deployment environment to let Spring make use of them, and then you're pulling together the pieces of an app server yourself (which may be ok, if you know what you're doing).

    So who's doing this? I'm evaluating these options right now myself, and trying to determine the enterprise-readiness of opensource infrastructure (i.e. no transaction logging in JBoss is a big no-no).
  17. Spring USES these services (JMS and JTA) but doesn't PROVIDE them. You'll need to integrate other libraries / servers into your deployment environment to let Spring make use of them, and then you're pulling together the pieces of an app server yourself (which may be ok, if you know what you're doing).

    With the parts standardized, it's not that hard or hack'ish to put them together.
    And I still see two major advantages in this DIY "app server" over any of the heavyweights:
    1. it's less prone to vendor lock-in.
    2. it manages to dodge the EJB container, which frankly I'm not sure most of the applications today really need except for 1) the "we are mission-critical" ego, 2) the "we've got to be clusterable at *every* tier" geeky architect, and/or 3) the "everybody else's using EJB" mentality.
  18. What do you get for the $$$$[ Go to top ]

    The problem with paying big bucks to a big company for support is: They don't really care about the small/medium guy's problems. You can point out a bug and they either acknowledge it and fix it a year later in a new release you have to pay more $$ for or they start pointing fingers at everyone else.....
  19. why pay?[ Go to top ]

    Why pay for licenses?

    - Operational robustness. The main "non lock-in" feature of the newer commercial application servers is about making sure the system does not go down, for planned or unplanned reasons. Sure, it may not be applicable to an average website, but this is the level of reliability that's being demanded by Fortune 500 customers that already use the OLDER infrastructure servers, whether CICS or Tuxedo or IMS or whatnot. Including things like fine-grained resource managers, side-by-side deployment / zero-downtime upgrades of applications, transaction dyeing, very high-speed + scalable messaging, support for the latest WS-* standards, etc. are not trivial (otherwise everyone would have it).

    - Extra features. Sometimes they're worth it, sometimes they're not. The database vendors have made a good business out of this. Frankly, I think way too many are obsessed with avoiding lock in. It happens. Yes, it should be managed. But it's a tradeoff, not a holy grail. Even if you use an open source project, you're effectively locked in -- you can either fork the code base, or you're stuck with the direction of that project. It's a business decision whether you want to run the risk of having to maintain the code, just like it's a risk that a proprietary vendor may go belly up. Which is more palatable? Depends on the context, I suppose. I think relying on a financially stable vendor is much more risk averse than betting you have developers that can successfully maintain an OSS codebase alongside their "real work".

    - Maintenance/support discounts. License deals often have drastic offsets to annual support renewals.

    - Bundles. Large integrated hardware/software companies can give major discounts on hardware if you purchase software license. (though this works too for OSS if you purchase large consulting contracts)

    - Indemnity. Large software deals usually imply an ability to tailor your own terms and conditions. Government agencies, for example, are notorious for negotiating 10+ year warranties, withholding revenue recognition until delivery, unlimited liability, and getting massive discounts on license and/or support. Do you really think a small support-driven OSS company can meet these terms? One successful lawsuit, and the tent is swept away.

    - License offsets consulting. Something has to fund development -- support fees can only go so far, and consulting is where a lot of that maintenance happens. In a way, I think open source advocates are treading down a path of "software as a service" without realizing what that implies. It does NOT necessarily imply a wonderful array of libertarian independent free agents using only open source software (though that model is working in some areas and will grow). It more likely implies that software infrastructure companies will have a subsidiary large system integrator that can dump busloads of green consultants charging $200/hour to fund product improvements. And it probably means that product quality will suffer so that there is incentive to purchase consulting.

    Large companies, as much as people like to think they're stupid, are not necessarily that stupid, they just have different priorities than most developers.
  20. a sad history[ Go to top ]

    I've been using BES for the past two years, and is not really good, we started with version 5.1 and it was a hard time, its a really heavy process , the cluster option hard to make it work, some critical bugs, the some time passed and we got the version 5.2.1 and it was better, but it is still heavy and often crash with an out of memory error, and when you try to deploy a file with the BES console it crash (i had to write my own deployer application in order to put my application in the server).

       The the version 6.0 arrived and my company bought it, it was a big mistake a lot of bugs ( many application working with 5.2.1 weren't working properly in 6.0 ) and problems with Jbuilder .We though that the problem were us , but when a few months later Borland release the version 6.5 with the fixes of many of problems the problems that we had, we realized that the problem was the server. We go back to 5.2.1 version after that.

        After that i felt like we were paying for a unuseful software that makes our work a hard thing. And if you ask me about support we had like a 15% of useful support it's not a great deal, i think so.
    So i am starting to check Jboss, and Tomcat alone they can do the most of things i need to, you can get the newest version for free and if this version is not working with you you go back to a prior version without any felling of guilty. And for support we have google, it is a big helper it has solved the 80% of our problems.
  21. I've written up a few blog entries on this topic.

    The benchmarks results are the most quantified way of looking at the problem, but that only covers hardware and software consumption. They key take away is that WebSphere and others may cost less/CPU than WebLogic, but they need more licenses and hardware to carry the same load.

    SPECjAppServer2004 Results Analysis

    The second way to look at this problem is to look at the relative cost of the app server vs. the total project cost. My crude analysis shows that the total licenses and support over three years come out to only about 2% of the total project cost yet the choice of the app server can have significant impact on the likelihood of success of the project.

    The Relative Cost of Application Servers

    Eric- BEA Systems
  22. The second way to look at this problem is to look at the relative cost of the app server vs. the total project cost. My crude analysis shows that the total licenses and support over three years come out to only about 2% of the total project cost yet the choice of the app server can have significant impact on the likelihood of success of the project.The Relative Cost of Application ServersEric- BEA Systems

    That depends on your deployment environment. If you're deploying on one machine or a small cluster, then sure. But what if you're developing a software-as-a-service offering that's going to be deployed on a 30 node cluster? Adding more customers means adding more nodes which eats into your margin. As you scale the licensing fees become a higher and higher percentage of your total cost, and people's time becomes less and less of a percentage. At some point it becomes financially beneficial to hire away whatever Geronimo developers IBM hasn't snagged to fix what you need fixed.

    Free / node scales a lot better financially than $10-$20K/node.
  23. The second way to look at this problem is to look at the relative cost of the app server vs. the total project cost. My crude analysis shows that the total licenses and support over three years come out to only about 2% of the total project cost yet the choice of the app server can have significant impact on the likelihood of success of the project.The Relative Cost of Application ServersEric- BEA Systems
    That depends on your deployment environment. If you're deploying on one machine or a small cluster, then sure. But what if you're developing a software-as-a-service offering that's going to be deployed on a 30 node cluster? Adding more customers means adding more nodes which eats into your margin. As you scale the licensing fees become a higher and higher percentage of your total cost, and people's time becomes less and less of a percentage. At some point it becomes financially beneficial to hire away whatever Geronimo developers IBM hasn't snagged to fix what you need fixed. Free / node scales a lot better financially than $10-$20K/node.

    You are right that any analysis needs to factor in the use case. I had to make certain assumptions to come up with my crude model.

    I agree that the use case you outline would reduce the % of cost attributed to development over time, but it is still the majority of the costs so it could take many years to make up for any lost developer productivity.

    I would also stand by the claim that a free app server that consumes more hardware can easily offset the costs saved by the license fee. If you need more hardware and OS licenses and the support, power and space that goes along with them, you can easily spend more by using a free app server.

    All of that said, it really depends on the use case and requirements that come from them. Sometimes free is the way to go. Sometimes it isn't. You can't paint broad strokes that say one is always the right choice. This is why BEA announced future support for open source frameworks and containers at JavaOne this year.

    Eric- BEA Systems