Slashdot Mirror
PHP Usage in the Enterprise
acostin writes "Some open survey results were published about PHP usage in the enterprise on the InterAKT site. An alternative survey on the PHP open source mouvement can be found on Zend site. See how we've evaluated the PHP market size($$$), what people think about PHP as an alternative to Java and .NET, and what should be done in order to have your large clients adopt open source solutions."
What problems have people had in trying to migrate their applications to php, and how did you overcome them? How would you sell php to your boss? Bearing in mind most of our applications aren't simple database-driven (and I used that word hesitantly!) ones like Slashdot - hint: banking and insurance sector.
I really enjoy using PHP for web development. I find that you can't beat scripting languages for ease of maintenance, quick turnaround time, and tweakability.
One of the big reasons I chose PHP was the availability of "LAMP": Linux, Apache, MySQL, PHP. I know these technologies have been around for years and will be around for many more years, so it's an easy sell to management. There's plenty of talk on the newgroups if you ever get stuck and PHP's online documentation with user comments is priceless. I think more documentation should follow this example.
That aside, the pure performance and reliability of the above is excellent. These technologies were made to work together, and from what I hear the teams even collaborate to make sure their stuff stays working together. It really shows.
Years ago I worked on ASP/SQL Server solutions and where you had to go with native code for high-performance with ASP, I find that with PHP it is high performance on its own.
Great job to everyone who has helped put together these technology solutions. A shining example of the high quality that can come out of the collaborative efforts of many.
When you've laid eyes on an Apache/AxKit driven site that uses XPathScript and XSLT, then we'll talk. You want completely unmaintainable content? First, you have XML files which somehow are supposed to respresent data. Nevermind that somebody is supposed to make some kind of heads or tails of these things. Second, you have either XPathScript (.xps) or XSLT (.xsl) which is somehow supposed to transform that XML into discernable HTML that a browser can use. In the case of XPathScript, you have an wacked hodgepodge of Perl and HTML. Nothing halfway understandable like an Embperl, Mason, or even Text::Template template or component. No, go look up XPathScript to see what I mean. XSLT stylesheets are no better.
I want to believe in the XML's mission, but when I recently took up a migration of someone else's AxKit driven site, I haven't been able to get much sleep (it's 2:28am on a Friday night and I'm rebuilding a server to accomodate this goofy setup).
I used to think highly of PHP when I was using it for small tasks (creating a blog page and a half ass forum) but man oh man does it suck for doing big projects. In the enterprise marked, there really only one player I'd look to and that is Java. Everything else is really irrelevant. Yes Java has a steep learning curve but once you get ahead of the curve you are never going back to whatever you were using. Java + Eclipse is a deadly combination.
-----
One is born into aristocracy, but mediocrity can only be achieved through hard work.
When I joined the IT department at SST (a fabless chip manufacturer), they were 100% MS. I said I would be using PHP or they would be hiring someone else. They hired me, so I went hog-wild. I hired on the guy who built edrugtrader.com, the guy who built beerotopia, and one of the developers of Yube (which is/was a primarily Java shop). We've built up a massive intranet product in PHP. It's modular, with 196 files all interoperating nicely. Thanks to our Yube guy, it's object-oriented in the most-reused parts. It has areas for file management, posting news, creating new Web pages with a built-in GUI editor (thanks HTMLArea!), org charts, a task management system, a budgeting tool, employee evaluation systems, a signoff system with escalations & delegates, a form builder, and a lot more. On a day when we post earnings, the intranet can see just as much traffic as the public site. We've sustained over 100 requests/second in a few spots, and done just fine. I know that's not Yahoo-size numbers, but it's not "small" either, I don't think. If it is small, I know that edrugtrader sees many times more traffic and performs well. So no qualms there.
The problems we've had with PHP were small in number and quickly resolved. First, 4.3.2 had a bug that resulted in blank pages displaying intermittently to our users. That sucked, but 4.3.3 fixed it. And way back about 3 years ago as we started the site, we had to increase the memory allotment for just about everything -- we had some big processes with hundreds of queries getting read into PHP arrays, and we hit the default memory limits pretty quick. Other than that, no problems. Development is quick, often easy, usually fun. If we need to go OOP, that's fine. If we need to do simple templating, that's fine too. And increasingly, we're using it outside of the Web. We have a dozen cron jobs now that are all PHP scripts. Some things, especially screen scraping and working with mailboxes, still need to be done in Perl. But lots of server management stuff -- filesystem work, data dumps, monitoring -- seems to be going along fine with PHP nowadays. I'm pretty happy to have bet my career on PHP so far.
My Greasemonkey scripts for Digg &
I'm not saying this is some ultimate solution, I've also missed exceptions badly, but if the application needs exception handling only in a few places it's quite simple to simulate them:
Far from beautiful, but you know a lot of "enterprise applications" have been written in COBOL, Fortran or C which none of them has exception handling AFAIK (if gotos don't count).