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.
A PHP Developer says:
April 14, 2009 at 6:02 pm
As a system administrator who has worked in both large and small IT shops, with Microsoft tools and Java, and who now works exclusively with PHP, I have to ask myself, what can Zend Server do for me? How will it help my current situation?
I’m not looking for another vendor to pay an annual subscription fee to. If the product is strong, I’ll buy it and I don’t mind paying a maintenance and upgrade fee but to charge me for a subscription for the product and have it revert to the free version should I not re-subscribe, well, that’s vendor lock-in If I wanted vendor lock in I would still be using Java, application servers and Oracle. PHP doesn’t “need” vendor lock-in to be taken seriously in large development shops.
I currently have a stable LAMP stack installed. Most of the tools that Zend Server offers me (with the exception of Zend Studio integration discussed below) are already available in open source forms. Many, like xdebug over Zend Debugger are actually superior tools. It is true that Zend does work to release backwardly compatible hot patches before they are available to the community but in my experience, the community responds fast enough to security vulnerabilities so that I don’t really feel the need for this service.
The one cool feature that isn’t easily replicated elsewhere is, as mentioned above, Zend Studio integration with the debugging. On the surface this is a great feature and in day-to-day development it would be great to have. However, to get more out of it than I can easily get with something like FireBug and FirePHP, I would have to load the debug module on a production server so that I can analyze errors in production. I don’t know a serious sysadmin who would ever consider doing this. So that feature, while cool and all, is of limited use.
Finally, when I asked Zend, how do I develop against the Enterprise features should I want to, I was told that I would need to buy a license and subscription for each of my developers. In this economy that’s a laughable answer, even at the 50% discount they are offering. A better answer was when they used to give development licenses away and only charge for production licenses. Alas, I think the man behind that was Mr. de Visser and that insightfulness seems to have left the building with him.
So the real question is not what can Zend Server do for PHP, anyone using PHP seriously can answer that question readily, “not much”. The real question that should be asked is what can Zend Server do for me, a potential customer.
As a side note, it would help if articles like this would stop assuming that PHP needs an “application server”, a notion that, given how PHP operates, is laughable. I for one would also like to see RedMonk have someone with some serious PHP insight analyze this product and the PHP market as a whole. You are a good man and obviously you know IT and Java well, but your lack of insight into PHP, the eco-system, and the community, means that most PHP developers and Directors of PHP shops will probably ignore this article. (sadly, most everyone else will likely ignore my comment) 🙂
Thank you for your time.
A PHP Developer
April 15, 2009 at 7:14 am
@A PHP Developer: I can’t and won’t, obviously, speak for the folks from Zend on this point, but let me respond to a few your core objections in brief:
1. The Zend Server featureset is replicable elsewhere
True, a portion of the featureset can be replicated using other tools, some of which are more mature. But there is a certain type of customer that would prefer not to assemble their own infrastructure, but purchase it in a single product.
2. The Zend Server features of interest are only available in the enterprise edition
Deciding which features are for free and which are for pay is generally a difficult decision for firms that operate in the open source space. The market will dictate whether or not Zend’s struck the right balance here, and I’m sure your input will be added to lots of other voices to determine the future product direction.
3. The Zend Server is replicating vendor lockin
Generally, the answer to this is: don’t purchase the product. It should not be expected that one approach will work equally well for all parties. Many large enterprises have happily locked themselves into proprietary product sets in categories ranging from the application server to office productivity suites in return for a simplified buying and deployment process. You may or may not agree with that decision, but it’s important to remember that the buying metrics are different for different customer sets. What might not work for you might work well for a different type of customer.
4. PHP doesn’t need an application server
The overwhelming adoption of PHP would agree, and yet there are many IT shops that will spring at an application server because it will make their PHP instances look more like their Java instances. Again, this may sound abhorrent to you, but for certain markets it’s likely to be hugely appreciated.
In general, I think you observations are important, but I would caution against drawing general conclusions about the product’s importance based primarily on your needs. Where you may have no or little need for Zend Server, it’s likely that other markets characterized by different needs than your own might find significant value in the product.
And if that grows the overall PHP ecosystem, it could benefit you, whether you decide to use it or not.
Joe Lea says:
April 15, 2009 at 12:15 pm
Good post. As a reminder, IBM is not just talking about PHP _and_ Java (vs PHP _or_ Java)… http://www.projectzero.org/php/
A PHP Developer says:
April 15, 2009 at 5:33 pm
A well thought out response to my points, I would expect nothing less from you. I believe though, that I may have failed to communicate my main point. When I said “I” and “me” I was speaking metaphorically. “What can Zend Server do for me” was really supposed to be “What can Zend Server do for the mainstream IT development shop and support team.
I keep being told that there are customers that would prefer to purchase a single product, you are not the first to say it and I’m sure you won’t be the last. However, in my little corner of the world (I’m in contact with 30-40 developers across the world on any given week) I’m not seeing that. Most of my contacts are outside of the Fortune 100 range, so I will concede my polling is not scientific. The LAMP shops that I see all prefer their own customized, and internally tested/approved, version of PHP. I can only think of a handful of shops that actually use the package manager to keep production servers up to date and some of them use it as a convenience with the source servers being internal and the packages are again, custom built. Unlike the Java world where you use the version that is pushed, PHP is a highly customizable tool and the shops I talk with take advantage of this.
Yes, the market will decide if the features they have selected to charge for are worth it or not. More importantly though, the market will decide whether or not they are willing to accept the risk of vendor lock-in for those features. As a side note withregard to priving and value, the current version lacks many of Zend Platform’s features like Session Clustering and centralized management. Without these tools, Zend Server’s value proposition has yet to be proven.
Your answer to the lock-in question is a bit simplistic and I’m betting one that Zend doesn’t want people to consider. To simply brush off the question of is Zend selling its customers nothing more than a license to pay Zend with a simple “don’t buy it”, doesn’t fly. Please don’t get me wrong, I have nothing against Zend. I respect the work that Mr. Gutmans and Mr. Surraski have done on PHP and they have every right to profit from the language they helped build. However, I would hope they would do so by offering a product that actually adds value to PHP, not simply adds a price tag.
With regards to your answer to PHP does not need an application server, I’m really not sure whether I should be amused because you are making a joke or insulted because – as someone at the Director level – you feel that I need a marketing term to help me understand Zend Server. When I worked in Java, I took the time to understand what it took to build large scale Java applications; I’ve done the same for PHP. Any one at the Director level in IT that is making technology decisions should be capable of doing this without having to resort to “Java has Application Servers, this isn’t the same but it’s close enough so if we call it an Application Server it will make them think they understand.” PHP does not now, nor will it ever, “need” an application server. Zend is using this term solely for marketing purposes and it does more to confuse than to clarify.
I do sincerely appreciate you taking the time to respond to my last post. Honestly, I wish we could see more eye to eye because, while it may not come across here, I have a great deal of respect for your work. It is only when you are delving into areas that I am knowledgeable in that I would dare call you to task for what I perceive as inaccuracies.
Again, I am in debt to you for your time.
A PHP Developer
Savio Rodrigues says:
April 15, 2009 at 8:38 pm
I guess “disruption” is too strong a word for my Canadian sensibilities. 🙂
Going back to late ~2006 we considered whether PHP apps in the enterprise were replacing Java apps. We found that the PHP apps were not replacing Java apps. Rather, the apps being built with PHP were apps that would either not have been built at all or whose purpose would have been served through shared Excel files, VB apps, MS Access apps or email.
In one example a company had built a PHP app for employees to document that they had upgraded their antivirus program to a new release. In the past, this was tracked by employees sending an email to an unlucky soul that had to keep track of such things.
Also, we found that most of these PHP apps were being built by casual developers outside of the IT department. For the most part, these folks did not have the skills to develop Java apps even if they wanted to.
Has PHP use in the enterprise moved beyond these simple CRUD-type applications? Absolutely. But ‘disrupting’ seems a little strong. I’d argue that VB has more to fear from PHP than does Java. But in the end, as we both agree, PHP, VB, Java, xyz all have a role to play in the market. Vendors that offer “and” solutions will be well positioned.
james governor says:
April 16, 2009 at 1:16 pm
some great thoughts here. but i think the key point is different roles. as we both know all too well enterprise IT is often layer upon accreted layer.
The Java application server market is certainly set for radical change, for example the IBM Sun scenario, which always creates opportunities for other players.
i think you have to mention Oracle bought BEA for context.
also pondering another redmonk client, IBM, with its ability to run PHP on WebSphere XD. See http://bit.ly/2PgNBE [PDF warning] I don’t know of any customer deployments, but I know IBM wouldn’t have built it unless a major customer was calling for it. IBM of course also partners with Zend, notably on IBM i, (nee AS/400, System i, etc).
James Governor’s Monkchips » Enterprise Software Sales as Corporate Pathology: The World’s Greatest Dog and Pony Show says:
April 17, 2009 at 7:03 am
[…] in a post about Zend’s new enterprise PHP server Stephen my business partner summed up the tragedy of […]
Kent Mitchell says:
April 20, 2009 at 9:08 am
I want to correct a couple of small errors.
First, one key value propositions of Zend Server is that ability to debug an event/error on a server other than the one the problem occurred on. The monitoring and altering component gabs the data needed to replicate the issue and stores it. This event can then be replayed on any Server. So if there is a test environment that replicates the production environment then it is easy to debug on those servers. So if as “PHP Developer” points out above the IT Admin does not want debugging capability on his production servers he can do exactly that. This is extremely valuable to our custoemrs not only for the reproducibility of the event but the ability to debug on test servers.
Second, there is no requirement to develop using Zend Server. Most of the APIs in Zend Server also exists in Zend Server CE which is totally free. The only exception is the programmatic interface to the URL based page cache. In most cases this API is not needed and the cache operates transparently. In the event it is being used when the Subscription expires the page cache and it’s API are going to be disabled but if you are depending on this functionality you have a much bigger problem than just the API not working.
That said we do think there is value in Zend Sever in development to support the replay of Events (the first item i mention) as well as for consistency of configuration and stack between production and development.
James Governor’s Monkchips » Corner Cases Can Kill Innovation 2: The Big Dogs Are Too Big says:
April 27, 2009 at 5:59 am
[…] No – what I had in mind, was the tendency of “innovation capture” by deep pocketed customers, where the needs of a tiny minority of customers dictate overall product generation, skewing the overall direction of innovation. A good example of the tendency in action is The Java application server wars, where BEA WebLogic and IBM WebSphere fought a death match throughout the late 1990s and into this decade for the high endian needs of a handful of customers, notably Charles Schwab and eBay. The thing is though- the really big dogs have different needs from the rest of the market. They are edge cases. Enterprise Java app servers became something for the high end, for organisations with huge developer teams with samurai skills. Of course BEA and IBM’s focus on serving the needs of the Big Dogs created opportunities for other players- such as JBoss, and latterly Glassfish and dynamic scripting languages and associated servers such as Zend. […]