I’m surprised by low traction of LAMP applications in an enterprise (I use the LAMP acronym loosely as a catch-all for PHP, Ruby and Python apps). For most large organizations Java EE still reigns supreme. While developers and analysts debate performance and “enterprisey” features (or the lack thereof) of the LAMP stack, there is one aspect that is often overlooked – LAMP infrastructure is much more simple than a typical Java EE application server, hence its operations and maintenance is greatly simplified. And of course operations and maintenance is a big chunk of IT budget of any organization; in many shops it is actually the biggest part of the budget (60% is the average according to Forrester).
It usually goes like this. Data center operations are outsourced, and so data center personnel has to provide the first line of defense for all production problems. Data center folks are not developers, so NullPointerException does not mean much to them. But they have to be able to figure out who to call when they see the NullPointerException.
Here is an example of an error message from an application running under WebSphere Portal. This message is 318 lines long and is completely inscrutable to all but a hardcore WebSphere Portal developer or administrator. The most ironic part is that in spite of multiple “caused by” in the text, the message tells us nothing about the actual root cause of the problem, which, most likely, is a classloader conflict. As a sidebar, why can’t an app server at least give me a warning during deployment about a potential class loader problem (especially since all the app servers, even tomcat, add dozens of jars to the classpath)?
On the other hand, here is an example of an error message I get from a python app implemented using django:
Validating models...
djtest.order: name 'test' is not defined
1 error found.
So which error message do you think will be more palatable to an operations person looking at the logs?
I know I’ve exaggerated a bit – my django app is extremely simplistic at this point. However, it is true that many Java EE app servers and applications do extremely poor job at exception logging.
Even more obvious benefit of LAMP is availability of the source code. In Java EE world, the common practice is not to include the source code into WAR and JAR files. In many instances, the code is compiled without debug information. Even if the source code and line numbers are available, finding the right file takes some digging since we have to deal with multitude of JAR, EAR and WAR files. Not to mention that the same class can reside in multiple jars.
So if I was the person who had to respond to the “site is down” calls late at night, I’d vote for PHP.
Apples to oranges…….
There are a ton of things you can do with java that you’d be foolish to implement purely with PHP.
I take your point, but the problem is not really Java EE, but really shoddy operational interfaces. Unfortunately nearly all the significant Java-based apps I’d worked with really stink in this department. Got a little error? Dump out a stack trace. This is just the wrong, wrong thing to do. LAMP doesn’t exhibit this problem because the only logging that exists is what you choose to write yourself….so you are forced to think about what you want to say. With Java, even if you do nothing you’ll get a stack trace, and regrettably many programmers either think that is sufficient or don’t bother catching it and turning it into something useful.
Steve, I’m always surprised how little developers think about the maintainability of their applications. I think LAMP people have more respect for that since they are usually more involved in supporting their apps. In general, LAMP code is easier to figure out too…