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."

php in a microsoft shop?

[ozric99]

I work in a large, predominately MS, corp. I'd say that a good 80% of our boxes are running some variant of Windows - obviously there are the mainframes, and a fair few Solaris/legacy boxes dotted around. The PHBs here view php as something "geeky" that isn't suited for business. I'm sure they'd lap it up in a second if it were called MS Visual php Studio, however.

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.

Love PHP!

[whereiswaldo]

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.

Re:Love PHP!

[prell]

PHP is decent, but its support of more linear, "c-like" code, is disconcerting. The object-oriented features are likewise minimized and somewhat poor. I would quickly use Python or Ruby in place of PHP, given the availability of sufficient support packages (eRuby, HTML templating, etc.). I do not really enjoy writing software in PHP.

ASP is commendable for its exposure of certain classes to all "ASP-bridged languages," making available such interfaces as those that handle state data (such as sessions), and for its language "agnosticism," given that a bridge is written (from what I understand). I really believe strongly that the open-source community should develop an answer to ASP to allow any language to run in a certain capacity in relation to the web (again, HTML embedding, a standard "web" library to expose features such as state data in a standard way).

PHP usage in an enterprise environment? It wouldn't be my choice for a substantial web application. Being OSS doesn't automatically make it a better choice.

AxKit, XML based sites even worse

[Fastball]

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).

Re:Love PHP!

[GundyRage]

"LAMP": Linux, Apache, MySQL, PHP

Or in my case "LAMP": Linux, Apache, MONO, PostgreSQL.

The truth is that it's sweet to have the right tool for the right job. Gotta love those options!

G

Re:php in a microsoft shop?

[NightSpots]

You're absolutely crazy if you want to use PHP for banking and insurance apps.

It's security record is horrible.
It's security model is a joke.
It's object model is worthless compared to real OOP languages.
It completely lacks exception handling, which makes rolling back partial transactions (etc) impossible in banking scenarios.
It's developers regularly break POLA on minor version increments.
It's database support is mediocre at best: third party classes are currently the best (but not only) DB interface PHP has.

Stick with .NET or J2EE. They're clunky, .NET is expensive, J2EE is slow, but they're both leaps and bounds ahead of PHP.

Re:Hack-away

[deli_llama]

When I was in school, in my Enterprise Systems class we had to design (as the final project) a true 3-tiered enterprise web application using Java and J-Boss -- a daunting task to complete in 3 weeks. So my group did the only sensible thing and re-associated the .jsp extension with the PHP processor and wrote the whole thing using php instead...and told no one.

We didn't take any shortcuts at all: we preserved a complete and separate true 3-tiered archetecture with all the fixins and everything. In fact, adding site-wide RSS output capability only took about 15 minutes to implement. We could swap in and out components with no effort at all.

The best part was that not only did we pull it off, but we were the only group to finish (Everyone else was dealing with the horrors of sluggish development that EJB invariably brings with it. Most were about 15% done.), but we were the only group to ever get full marks on the assignment.

EJB is for managers and people who want to be sold a solution. PHP is for developers who know what it takes to build a solution and want to get it working, get it working right, and get it working right now.

Re:heh

[Skim123]

As a Web developer who has created Web applications in both PHP and ASP.NET, I can say, without hyperbole, that ASP.NET is one-million times better. Ok, so maybe there's a little hyperbole in there, and I know I'm just feeding a troll with this post, but I would wager that anyone with extensive experience with both PHP and ASP.NET would, at minimum, say ASP.NET is par with PHP, but would likely express that ASP.NET is better in a variety of areas. About the only negative for ASP.NET is its lack of cross-platformness, but with Mono and such, who knows how long this complaint will hold merit. Too, having Apache serve ASP.NET Web pages on a Windows box is something that is doable.

J2EE is not slow

[Kunta Kinte]

Stick with .NET or J2EE. They're clunky, .NET is expensive, J2EE is slow, but they're both leaps and bounds ahead of PHP.

I can understand why people think that Java is slow, taking that Java GUI widgets are usually slower than native widgets on the desktop. But J2EE is not inheritably slow.

Though there are clunkly J2EE apps out there, I'd wager on a hunch, that the average J2EE app would out-perform a same sized PHP app. If we add a PHP accelerator to the mix, like Turck MMCache [turcksoft.com], then PHP may have a fighting chance.

But remember, J2EE compiles the web application only *once* at startup, and can also ( and probably does ) optimize for the specific processor that it's running on. PHP, without an accelerator compiles on every hit, and PHP can't optimize for the specific processor unless you have a good sysadmin.

Re:The code is the data!

[saden1]

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.

SST & edrugtrader (nice combo, btw)

[Anthony Boyd]

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.

Re:Hack-away

[jorleif]

Did you build the entire application in PHP, or only the "presentation layer"? I mean was there any Java in it, for instance in the database layer?

As a PHP-developer who maintains a fairly large site and intranet I've come to both love and hate PHP. Love it for it's development speed and ease. Hate it for its lack of static analysis, I mean yes the language is dynamically type-checked but that doesn't mean the interpreter couldn't check whether some code calls undefined functions or defined functions with the wrong amount of arguments at parse time so it would catch these errors without one having to test every code-path.

That and then the scoping absolutely terrible but most people know that already. That said I still believe PHP is a better solution than Java on the whole. Neither is really optimal but both are fairly good.

Re:The code is the data!

[jorleif]

Exceptions are required for enterprise quality applications.
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:

1. Wrap the function which throws the exception in a class
2. If the exceptional condition occurs have the function set a description in an instance field named for instance "exception" and then return
3. The client code calls the "getException"-method in the class of the function throwing exceptions
4. If exceptions occured, deal with them, otherwise proceed

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).

My experience

[Alien Conspiracy]

Having used both PHP and J2EE for major projects, I'd have to say that I prefer PHP because:

1. It is more concise - java even _less_ compact than C++ with a good set of libraries - whereas PHP has loads of very forgiving high-level functions builtin.
2. It is more lightwight - java is just _still_ too bloated and slow even after all these years of promises from Sun.
3. The Java VM's for Linux really suck, they 'officially support' only RedHat and are unstable as hell running on Debian.

That said I really miss the J2EE ability to cache persistent data between requests in memory simply by declaring a variable as static. It's the only feature I miss in PHP.

As far as .NET goes, it never reached my radar since it is Windows-only.

Presentation on PHP Adoption

[ubiquitin]

Here's a presentation about what the following tech companies have publicly said about PHP:
Macromedia, IBM, Oracle, Sun, Apple, Symantec, Novell, Microsoft, MySQL

http://php.ist.unomaha.edu/presentations/secondc la ss.pdf

I think the biggest news is that Oracle is putting the PHP module into their 9i Application Server.

The code is the data in FP, not in PHP

[axxackall]

PHP code does not see (reflect) itself as data, no reflection in PHP. The code FUNCTIONS are not first class objects. So, that's why in PHP the code is not a data from FP (Functional Programming) prospective.

IN FP languages, like Lisp, the code is the data: there is very well defined reflection, I can construct new functions and manipulate existing ones as they are first class objects. Same/similar situation is in ML and Haskell.

Well, among traditionally imperative programming languages there are more and more cases of "the code is the data" paradigm as well. First of all in iterpreting (scripting) languages, like Python, Perl and Tcl. You can construct the text of the function and "eval()" it. The problem is that in FP languages there is a very well designed math model for it protecting you from many errors (you construct real functions, not a text for for functions). In scripting languages it's more like a hack leading to many errors in a similar way as C pointers and Fortran GOTO operators.

Re:Hack-away

[deli_llama]

No, we actually did build an entire 3-tiered application in PHP. First we built an application framework, similar in functionality and purpose to JBoss. Then we started at the bottom and built separate modules to perform individual tasks -- the presentation logic, the business logic, database interaction, etc. Each layer was absolutely independant, linked to the application as a whole only by the framework. If we wanted to use a different database, all we had to change was the database layer. If we wanted to change the presentation format (HTML, PDF, etc.) all we had to do was tell the framework to use a different presentation layer.

Perfect? No, No. We only had 3 weeks to develop it. No project of that magnitude is flawless in 3 weeks. It was, however, indistinguishable from perfect in all the important ways for that class (function, maintainability, expandability). The problem with n-tiered development with PHP is that it takes a lot of dicipline to do it the right way instead of one of the myriad easy ways. The rules of separation are enforced only by yourself, and not the language or framework. It takes more work, but it pays later when you have to maintain it.

Cheat? No. Be careful not to make such bold accusations on such little knowledge. We cleared everything with the professor first, and only hid the details from our fellow students because it was doubted that others would build a true n-tiered archetecture if they could use PHP. My group was already very accomplished in this area.

Afraid to hire one of us, you say? You'd be missing out. One of us got a job specifically because of this project and is now teaching others to do this sort of rapid-but-maintainable web development on a larger scale. Another one of our team (still in school) has created and maintains a number of well-known and extremely widely used PHP-based tools. And me? I get paid an obscene amount to do what I used to do just for fun. That project helped me out quite a bit, too.

So yes, it's possible, we did actually did it. It worked perfectly, and it turned out to be a very profitable undertaking for us all.

The need now is an OLAP api and servers

[Nicolay77]

I love the idea of have used php which I know well to create our OLAP enabled services.

But there are no available good Open Source OLAP servers (just something in the works with Java). So I'm using ASP which is ugly but has the powerful MS olap server. I don't like to use MS products, but in this case is the one with the most favorable cost/benefit ratio.

Want to increase PHP market share... integrate it with OLAP technologies. Help Open Source OLAP technologies. You will increase marketshare and I will use something nice, stable and open.

I'm still slightly annoyed...

[Dr.Dubious DDQ]

...that so many people assume PHP is "only for web pages". The entire first report linked above seems predicated on the notion that "PHP is for companies to make money setting up websites for other people, and other uses are 'fringe' or irrelevant."

PHP is definitely good for web-pages, but I've increasingly found it to be very useful for a lot of command-line programs and system administration, much as Perl is.

PHP-GTK has also already been mentioned in other postings, and the increasing interoperability with Java means you can implement a variety of parts of your PHP projects in "native Java" if you want to...and that's not just "Java for web pages" code, either.