OK, out of respect for your time, now that I’ve caught you with a title that promises some drama I’ll cut to the chase and tell you that I definitely lean toward the former. Having spent a couple of days here at Oracle Open World poking around the various flavors of Engineered Systems, including the established Exadata and Exalogic along with the new SPARC Super Cluster (all of a week old) and the newly announced Exalytic system for big data analytics, I am pretty convinced that they represent an intelligent and modular set of optimized platforms for specific workloads. In addition to being modular, they give me the strong impression of a “composable” architecture – the various elements of processing nodes, Oracle storage nodes, ZFS file nodes and other components can clearly be recombined over time as customer requirements dictate, either as standard products or as custom configurations.
I don’t understand why firms spend millions of dollars on Java application servers like Oracle Weblogic or IBM WebSphere Application Server. I get why firms spend money on Red Hat JBoss -- they want to spend less on application servers. But, why spend anything at all? Apache Tomcat will satisfy the deployment requirements of most Java web applications.
Your Java Web Applications Need A Safe, Fast Place To Run
Most Java applications don’t need a fancy container that has umpteen features. Do you want to pay for a car that has windshield wipers on the headlights? (I wish I could afford it.) Most Java applications do not need these luxuriant features or can be designed not to need them. Many firms do, in fact, deploy enterprise-class Java web applications on Apache Tomcat. It works. It is cheap. It can save tons of dough.
Expensive Java Application Servers Sometimes Add Value
There is a need for luxury. But, you probably don’t need it to provide reliable, performant, and scalable Java web applications. Application server vendors will argue that:
You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container. Many applications don’t even need Spring. EJBs are not needed to create scalable or reliable applications.
Before Java was invented, one of the key industry trends was to increase the productivity of both developers and end users. For example, fourth-generation programming languages (4GL) such as Powerbuilder, Progress, and Uniface provided professional developers with faster ways to develop business applications than using COBOL, Pascal, C, or C++. For end users, tools such as Dbase, Lotus Notes, and Visicalc provided them with the unprecedented ability to create mini-apps without the need for professional developers. In the early '90s, this productivity trend was thrown into a tizzy by the Internet. Now, software vendors and enterprise application developers had to rush to write a whole new generation of applications for the Web or risk becoming irrelevant. The Internet forced developer productivity and 4GL’s to take the back seat.
Java Was At The Right Place At The Right Time For Web Applications
Java was designed in 1990 as an easier and more portable option than C++ to develop embedded systems. The invention of the WWW in 1993 started a meteoric change in IT application development. Sun Microsystems moved quickly to take advantage by selling “network” servers like hotcakes and offering Java as the platform for Web development. Most other software vendors were caught off guard and Java became the de facto Internet development standard for enterprise Web application development.
Today, Google announced Google App Engine for Business, and integration with VMware’s SpringSource offerings. On Monday, we got a preview of the news from David Glazer, Engineering Director at Google, and Jerry Chen, Senior Director Cloud Services at VMware.
For tech industry strategists, this is another step in the development of cloud platform-as-a-service (PaaS). Java Spring developers now have a full platform-as-a-service host offering in Google App Engine for Business, the previously announced VMforce offering from salesforce.com, plus the options of running their own platform and OS stacks on premise or in virtual machines at service providers supporting vCloud Express, such as Terremark.
What’s next? IBM and Oracle have yet to put up full Java PaaS offerings, so I expect that to show up sometime soon – feels late already for them to put up some kind of early developer version. And SAP is also likely to create their own PaaS offering. But it’s not clear if any of them will put the same emphasis on portability and flexible, rich Web-facing apps that Google and VMware are.
So Google aims to expand into enterprise support – but will need more than the planned SQL support, SSL, and SLAs they are adding this year. They'll also need to figure out how to fully integrate into corporate networks, the way that CloudSwitch aims to do.
I was lucky enough last week [22 March 2010] to moderate a panel at EclipseCon on the future of application servers. The panelists did a great job, but I thought were far too conservative in their views. I agree with them that many customers want evolutionary change from today to future app servers, but I see requirements driving app servers toward radical change. Inevitably.
The changes I see:
Get more value from servers, get responsive, get agile and flexible
Sikka made two comments that indicate how he's thinking about the NetWeaver portfolio.
1. In response to my question about whether SAP is concerned that Oracle's ownership of Java will put it at a disadvantage, Sikka started by highlighting SAP's work on Java performance, but then noted the availability of good open-source Java software to support the requirements of SAP customers.