PHP, Enterprised!

October 18th, 2004 • PHP

I’m sure we’re all bored with all these discussions about PHP being ready (or not) for enterprise computing; I know I am.

I think we’re all missing the point here, like Marco Tabini said, it doesn’t really matter if PHP is enterprise-ready or not, an enterprise-level company doesn’t care if you’re using PHP or mashed potatoes to get the job done, if the budget allows it then by all means use whatever you want. Nobody’s interested in hearing three-letter buzzword-like acronyms, nobody cares what you’re doing underneath, just as long as you make sure a patient’s heart doesn’t stop, or tons of money aren’t transferred by mistake to Nuke-The-World organization.

Yes, PHP is enterprise-ready, if you want it to be. It can do whatever you want it to do, from messaging, to RPC, to persistence, but are you willing to invest?! Are you willing to develop modules, extensions, APIs and standards? PHP is a monolithic monster, it’s not easily extended, but it still has lots of advantages, lots of potential, but are you willing to invest?!

Developing any project with PHP implies many costs, this includes the learning curve, integration, interoperability, deployment and obviously speed of execution. Each comes with a certain cost, each impacts a project in a different way, and each contributes to moving PHP further into the enterprise market.

Learning Curve

I’m not going to get into a scripting vs. programming language debate, but PHP is by nature a scripting language, and that exactly what made it successful. PHP makes it easy to develop software, sometimes this results in sloppy code, but then again, that only happens with sloppy programmers. The shallow learning curve made PHP Yahoo’s choice. Let’s face it, in spite of the mish-mash utility functions, unordered manual, non-standard API, lack of naming conventions, and the loose (maybe too loose) interpreter, PHP was able to almost dominate in it’s domain, it even outgrew Perl! Was it all because of Zend’s great marketing strategies? Was it because people like free, as in beer?! Or was it because people learned so fast that other languages could not keep pace?!

A shallow learning curve is always an advantage. I know a lot of people and companies who won’t even consider Java or C# for new projects simply because it cuts a chunk of the reserved budget to train programmers. They usually stick to “if it ain’t broken, don’t fix it”.

Integration and Interoperability

Now this is a tough one. PHP’s integration with existing software almost always becomes an administrator’s nightmare. Sure, with all its extensions it should be fine, but in reality it isn’t, since in most cases custom extensions and modules need to be coded for PHP. PHP needs to be able to talk to existing software, no matter what language it speaks. I know we’re all fed up with memorizing all sorts of acronyms, like WDSL, RMI, JMS, JST, JBXD16 or whatever, but PHP needs all those in order to sell.

Integration costs money. Usually if a solution is available, nobody’s going to reinvent it or port to another language, say, like PHP. Companies look for out-of-the-box solutions, ready to run and willing to plug into any kind of existing environments. Sadly, PHP can’t yet provide that.

Here’s a wild idea, let PHP have a Perl extension! Let it be able to run any CPAN module, within PHP, let it make use of Python’s standard library, it’s been done with Java and COM, so why stop now? Interoperability, that’s the keyword. If PHP can be plugged anywhere and actually make use of existing solutions, no matter how they were made, who’s going to say it doesn’t fit the enterprise? Just don’t fight other languages, embrace them.

Deployment

Well, compared to mod_perl, PHP’s deployment is a walk in the park. For simple software, it’s only a matter of copying everything, modifying a configuration file and a call from a browser. But then the nasty part comes. PHP’s monolithic design in most times requires recompiling just to add support for a single module. This shouldn’t be the case. PHP should have a tiny core that loads modules on the fly, whether or not they were compiled during PHP’s build process (and no, dl() won’t work here). It’s already difficult enough to deploy ionCube-encoded files to a shared hosting provider, don’t make harder to deploy more complex code.

Deployment in enterprises is an important issue, no administrator likes to do the work 100 times on different machines only because the process can’t be automated. Nobody’s willing to compile on every single machine just to get a PHP accounting application to run. Deployment of more complex software must be a breeze, runs with a single command, automatically updates from known mirrors, and does much more than just nagging and throwing errors on my terminal.

Speed, Speed, Speed

Not that Java is fast, but combined with caching, persistence and lot of tuning headache, Java can run as fast as C++. What PHP needs is to come bundled with opcode caching, probably even compile to bytecode, or even native machine code, that should speed things up. Make use of Apache, I mean real use. PHP is still not thread-safe, it doesn’t even have threads in the first place, it can’t make use of shared memory, it can’t do many things required in critical applications. What developers should do is to stop binding PHP with GTK or Qt unless it runs fast enough to handle it.

Compare mod_php to mod_perl or mod_python. mod_php does almost nothing more than parse a bunch of scripts and execute them, while it should give me access to Apache’s internals. I, as a developer, should be able to stick a PHP script in the middle of a filter chain, know exactly what’s going on, I should be able to write Apache modules using PHP, why not even compile a whole application to an Apache module, maybe then we can say PHP competes.

Final thoughts

This wasn’t meant to be a rant, and I apologize if it sounded like it. I like PHP, for all it’s good and all it’s bad. I only hate to see PHP being stuck in nowhere. Improving OO or mocking other languages is not the key to the enterprise. Yes, PHP is enterprise-ready, but like Jeff Moore said, maybe not all enterprises, at least not just yet.

You can skip to the end and leave a response. Pinging is currently not allowed.