It would be misleading to assert that the rise of Java within the enterprise was purely a function of the evolution of the application servers that today serve as the languages primary vehicle. But there can be little debate that the early products like WebLogic, later acquired by BEA, were instrumental in assuring Java’s place within the enterprise. Which is why it’s no surprise to see the interest in Zend’s recently announced server products; can it do for PHP, the questions are being asked, what its Java predecessors accomplished before it?
In the early part of this century, the discussion about Java more or less began and ended with the choice of the application server. Enterprises I worked with in a systems integration capacity would do the traditional dog and pony show, having vendors come in and pitting them against each other in bakeoff death matches which were guaranteed to be irrelevant to the actual project needs and unlikely to reveal anything more than the relative strength of the sales engineers in question. On this flawed process hung the technical fortunes of many an IT shop, so important was this platform.
Is it likely to be the same for PHP? Probably not. While I certainly concur with Zend’s Andi Gutmans when he tells Dave Rosenberg that “the Java disruption by PHP is well under way,” it is nonetheless true that Java and PHP remain very much different tools for different jobs. True, the maturation of the PHP language – in the object orientation sense, not least – makes it at once more credible and more accessible to the legions of Java programmers toiling away for the enterprises of the world.
Also true is that the newly launched web application server will dramatically reduce one set of barriers to entry for PHP. The server offering, the product of five years development, is without a doubt a very welcome development for the PHP language as far as I’m concerned. Not that the features it offers, which include the clustering, management, queuing and such typical of an application server product will be necessary in every PHP project – far from it. But for the first time, IT management shops will be able to deploy, run and manage their PHP instances much as they would their Java, which does change the game. PHP can now play with near equal credibility at the tinkerer and mission critical levels, which is unusual.
Still, I remain skeptical that Java and PHP will compete as directly as some of the headlines might imply. Not that I disagree with the assertion, as does Savio, that PHP has disrupted Java. That’s an easy case to make, in my opinion, if only because the old “the answer is Java, what’s the question?” could conceivably get you fired these days when it has been clearly established that for many tasks, PHP – or Python, or Ruby, and so on – is likely to be a better choice. But application server or no, there remain many reasons for enterprises to stay the Java course, hence my eventual agreement with Savio when he says that the “use of Java and PHP (and other dynamic scripting languages) together is much more interesting to customers than an “either/or” discussion.” Much like MySQL and DB2 or Oracle, I’d expect Java and PHP to occasionally run into each other, more frequently laboring side by side within datacenters on workloads differentiated by their volume and
Truer words, and all that.
What’s most interesting to me, then, about Zend’s work here is not what it does to harm Java, but what it can do to help PHP. Because in a world where the tax application that the IRS will use to process everyone’s returns tomorrow is written in COBOL dating back to the 60’s, it seems unlikely that we’ll see wholesale migrations away from the Java platform to PHP. But it’s far from unreasonable to expect that we’ll see entirely new workloads migrated to PHP because of the Zend Server.
Disclosure: Zend is a RedMonk customer.
