Saturday, June 17, 2006

The IROADS Syndrome

In the next lines I'll be speaking mainly about Java enterprise applications (especially web application built on a J2EE platform) used by non IT companies as business operational applications where manipulating data is the core of the system.

Some of the Java people who develop them suffer from what I would call the "I Run On A Dedicated Server" Syndrome, meaning that they code as they had at their disposal a server with infinitely extensible resources (CPU, RAM and HDD) and most important of all, all the resources are dedicated to their one and only application. Strangely enough - or maybe not - the same kind of people always say that hardware is getting cheaper and cheaper, so if you're in trouble, buy more RAM, HDD or CPU, or buy a larger sizer box if you need it (well, that's partly false, go over at IBM, DELL or SUN and see their prices for both Unix and Windows servers, but I agree that the general trend is downwards). The problem of this approach is that a company never uses a single application in their business, their number is fluctuating depeding on the company's strategy, it may increase with specific developments or it may decrease by acquiring some ERP or other technologies. Nevertheless, the demand in hardware resources is continuously increasing with the increasing offer of business software solutions on the market. It is then only natural at one point to think of mutualised environments for many reasons : costs, maintenance, monitoring to name only a few. That's how multiple applications get to run all together in one place and they get to share the same hardware resources more or less painfully.

The reasons for the IROADS syndrome seem quite obvious. Software development is an industry whose dynamics is continuously accelerating, project lifecycles get shorter, people concentrate on functional issues and the technical ones are delegated more and more to frameworks, containers, code generators and others. That's perfectly nice and maybe that's the way to go in the software industry, all of these facilitate the job of developers who can dedicate themselves to writing business code. But there's something people in general (not only developers) tend to forget, and that's performance - mainly speed and scalability - which cannot be entirely delegated to hardware components, especially in mutualised environments. And poorly written code or bad database tuning will perform badly on any system, hardware cannot do magic. Not taking seriously into consideration performance issues from the beginning of the project produces higher costs at long term due to code rewriting necessary to make the application perform better, which can be a great pain once you have an up and running business application. Personally I think that complex business use cases must be dealt with high attention regarding performance issues and you might have to write new code instead of reusing existing one even if it means higher costs. It might seem more expensive at the beginning, but it surely is a whole lot cheaper than rewriting after the final release is out. Java is simple, basically anybody can program in Java and when the code you need to write is only busines code, things are a even simpler, so not always the best programmers write the code - sometimes I have the complete opposite impression, but that's me. My opinion on this is that Java is indeed simple and clean, the J2EE standard is also fairly simple, but writing scalable J2EE web applications is bloody difficult, and scalable in a business operational application means a few hundreds of concurrent users, not thousands or tens of thousands. That requires experience on the server side and some basic but very sane best practices, like how do you limit the memory consumption, the number of context switches or the number of I/O operations and maybe most of all getting rid of the IROADS reflex when you code and think that you share memory, CPU and disk resources with other applications or other user sessions inside the same applications.

The effort of writing code which performs well has its costs and they may not be always justified. If the application is critical enough for the business, then it really is worth getting a little paraniod about performance issues, otherwise some poor code might do as well... or not, think of the mutualised environments:)