It’s true that the trip out to California is a bit more involved from Maine than from Denver, but the Zend Conference was – predictably – worth the trip. Even if it was in the cavernous San Jose conference center. As one of the larger gatherings of PHP types, it’s an opportunity to take the pulse of an increasingly important language ecosystem. Herewith a brief report – I’m coming off a red eye, so it’s in everyone’s best interests – on the present and future for PHP.
PHP and the Mainstream
Enterprise technology adoption is an interesting process, one that people can and have written books about, but perhaps its most defining characteristic is speed. Or, rather, the lack of it. As CEO Andi Gutmans put it, there’s a difference between being ready for the mainstream and actually being mainstream. PHP has, in the eyes of many including IBM, been ready for a while now. Years, actually. But having Deutsche Telekom on stage to discuss its decision to leverage PHP in a fashion far more strategic than tactical is just another validation point: the one time second class citizen of the enterprise is poised for a role alongside Java and .NET.
Perhaps the most impressive thing I heard from Petra Ruehl, DT’s VP of Product Development, was their willingness to challenge the conventional wisdom. Where other enterprises question PHP’s ability to scale for no other reason than the fact that it’s not Java, the German telecom giant (234K+ employees / 63B+ euros revenue) looked around and saw that there were in fact a few social networking sites that seemed to be scaling just fine with the dynamic language. And they took a chance on it two years ago, and were happy they did. So happy they came to talk about that decision here.
The question for PHP is whether Deutsche Telekom is an outlier or an indication of things to come. My bet is the latter; the momentum behind the language just can’t be denied.
PHP and the Cloud
The Zend folks were kind enough to ask me to moderate a panel for them entitled Developing on the Cloud. It was an interesting session for me, not least because all of the questions I took from the audience came in via Twitter, as did some very candid real time feedback on the panel’s worth. The panelists and I discussed the cloud and its implications for developers, from framework to management to security. What was interesting, I thought, were the repeated calls for an App Engine like option for PHP.
This to me is an open opportunity, either for Zend or another interested party. Most of the other dynamic languages have dedicated cloud platforms available for usage. Ruby has Heroku and Engine Yard, Python Google App Engine and so on. But while PHP developers have made support for the language the most requested feature on App Engine and even accumulated just shy of 3500 signatures on a App Engine based petition, there is no Heroku for PHP at the current time. I can use PHP in the cloud, for sure, whether it’s on IaaS offerings like Amazon’s or more PaaS-style offerings like Azure.
But sooner or later it seems probable that a commercial entity will conclude that the ubiquity of PHP and the inevitability of the cloud might make a winning combination.
PHP and Observability
Those of you that have followed my interest in Sun’s DTrace project will understand why I think the code tracing feature introduced in the latest iteration of Zend Server is an excellent idea. I can’t decide if it’s more horrifying or surprising that it’s 2009 and developers are still, for the most part, building on top of what are – effectively – black boxes. You can tell what happened before, and you can tell what happened after, but in between you’re pretty much limited to turning errors on and throwing debugging statements around like confetti. The demo I got yesterday however showed a server capable of contextually applying, via rules, a tracing function to specific error conditions. The performance hit is not major, but even better it will essentially look at a hash of the error fingerprint before writing it all out to the database. So if you get a flood of the same error, you’re not overwhelming the server by recording the same trace hundreds of times.
Part of making tracing useful, however, is intelligently and cogently rendering the collected telemetry. The data’s not particularly useful if you can’t read it, after all. Back in my mainframe days we had one guy working for us who could read a hex dump like it was a comic book – to the rest of us it was Greek written in Kanji. The Zend Server, to their credit, has a usable interface for the tracing functionality. It’ll be improved over time, I’m sure, but the current state will provide developers with a pretty good idea of precisely what went wrong, when things inevitably do go wrong.
You won’t be surprised to learn that I think that what’s really interesting to consider is what might become possible if that telemetry is centrally collected and analyzed in the aggregate, but more on that later.
Disclosure: Forgot this earlier because I was fresh off the plane: Zend is a RedMonk customer, as is IBM, Microsoft and Sun. Amazon, Heroku, Engine Yard and Google are not customers.
