Why Enterprise Web Scalability is Science Fiction:

1. You Use PHP to Troll WHOM?!. The wherefore of this article and an introduction.
2. Even the Pros are Cons. Why PHP’s advantages in enterprise are a form of backhanded compliment.
3. Sinking a fleet of FAIL. <——THIS POST Reasons for why PHP should not be used in enterprise fail you.
4. Time to set my phasers on “kill”. Deconstructing the use of the word of “enterprise” as an adjective modifying “web development.”
5. Defensing the indefensible. Don’t bother defending your B.S. it only makes you look more stupid.

Onto the second part of the article, where the author shows why PHP, the language used for the busiest sites on the internet, apparently can’t scale it’s way out of a paper bag:

Oh c’mon and get serious. At least read up on a subject before posting an article about so full of holes it could sink the Titanic three times over and have enough left to take out the Japanese whaling fleet.
—Pádraic Brady commenting on the article

All aboard the Failboat

[Destroying the myths of thread safety, performance, security, and scalability after the jump.]

Thread safety and performance

PHP is not thread safe—which means that multiple instances of the same routine may interact with each other, resulting in a crash on the Web server.
—CIO Magazine

This is clear mischaracterization for it implies that because PHP is not thread-safe, that it will crash the webserver:

The author should have said, “PHP is not intended for installation on threaded webservers” instead of giving the false impression that when installed correctly on a prefork server, that your applications will just crash because they don’t properly support threading.
—commenter on the article

This statement similarly implies that there are security problems with PHP, and that it is inherently unstable. Both are false. PHP sites do not require thread safety because user-land scripts are not threaded. Arguing against the language because it uses the standard unix [multitasking] method of forking instead of the windows-esqe method of threading is similarly invalid. Implying that forking causes stability problems is inaccurate and misleading especially as the majority of web servers operate every day using forking without any issues.
—commenter on the article

In fact, this increases stability because the processes exhibit a shared nothing architecture.

Zend Optimizer ⊄ compiler caches

Oh well, now let’s get to the possibly libelous statement:

PHP is sometimes criticized for being slow, and detractors claim that it has somehow been crippled in order to prompt users into purchasing the Zend Optimizer
—CIO Magazine

I say it is possibly libelous because it is a lie and clearly designed to denigrate Zend which operates in the same space that CIO’s target audience: enterprise.

Zend Optimizer is a FREE download and even a cursory fact checking would have exposed just how profoundly ignorant the author is in the subject matter.

Including such a statement is reckless at best.
—commenter on the article

To verify such a ludicrous, and probably [libelous] argument before publication is the job of an Editor. To even repeat a suggestion that PHP was somehow crippled PHP in order to drive purchases of Zend’s $0, free software, of which there are numerous other free alternatives, including the now-built-in APC is absolutely, patently, wrong — not to mention absurd — worse, it simply mischaracterizes both Zend’s intent, good will and their relationship with the PHP community.

You should apologise for this statement as it has no basis in fact.
—commenter on the article

The author of the article is confusing two Zend products. I’ll talk more on that later.

Security

PHP has suffered its share of security problems…PHP isn’t inherently insecure. But it has so many easy-to-use functions that, unless you use it wisely, you can get into real trouble.
—CIO Magazine

That’s a weird and contradictory set of statements. PHP’s security problems are due to a lack of education, not by design. In other words, “What functions might that be? And haven’t we already beat this horse dead?”

Sloppy programming can cause security issues? This is true of any language.
—Paul commenting on the article

As for “security” the author’s comments are completely ridiculous. If I buy a hand saw it doesn’t make me a carpenter. If I then accidentally cut my arm off with it, it’s not because the saw is not secure. PHP is tool and tools can be used incorrectly in inexperienced hands.
—Choppsta commenting on the article

“Register Globals, we’ll always have Paris.”

For the average PHP novice, bringing up register_globals is tickling the dragon:

First is the issue of global variables: variables that are available without declaration, available throughout the scope of the code and used throughout a page or script.
—CIO Magazine

I actually don’t have much a problem with global variables. The reason this is a security problem is far more subtle than being “available without declaration,”:

The author does not really understand the “register globals” issue. It’s not about “declaring variables before use” it’s about automatically registering a plain global variable for every http request parameter passed in regardless of whether it came from a POST, a GET or a COOKIE. And, yes — it’s fixed permanently in 6 and has been fixed by default since 5.
—Yardboy commenting on the article

In other words, it’s the subtlety of GET, POST, COOKIE, SERVER rule ordering that makes register_globals a potential security problem.

There is a small error by the commenter. PHP 4.2 was a legendary release for most ISPs. It was the release that turned off register_globals by default. So via Nexen.net’s widely available survey we can see that PHP versions before 4.2 comprise less than 0.9% of installations on the internet! (Let’s not forget we are talking about enterprise where they not only have control over the server build, they can also mandate browser client and version across the institution.)

It is safe to say that no new PHP development uses register_globals, and including it is like contrasting the safety record of a modern car, by complaining the 2002 model didn’t have an air bag. This is 2008 — and the authors statement is pathetically dated.
—commenter on the article

(We’ve had a factory recall on those models out there for the past six years.)

Even as such, register_globals development was never a substitution for proper input validation, and as such a professionally developed application using this facility would still be both secure and operational, even if the syntax was not ideal.
—commenter on the article

The chance of code injection can also be largely reduced by careful design.
—Andrew Z commenting on the article

Indeed.

Faceplant

The most damning observation was when it was noted that the CIO Magazine website uses Drupal, which is written in PHP—I guess they don’t care much about security:

The author writes about security but for some mysterious reason your very website is powered by drupal 4.7.7.
—Maciek Iwanowski (along with seven others) commenting on the article

Most security issues in the PHP world are userspace vulnerabilities. To give you an idea, in the NIST NVD, over 40% of all entries were by PHP applications by themselves.

Security flaws in the PHP language itself accounted for less than 0.5% of the flaws in the database. PHP application security flaws were 80x more prevalent!

Now while Drupal didn’t make Finkler’s Insecurity Top 20, I did get 100 hits in the NVD for Drupal!

Quantity is no substitute for knowledge

The PHP manual has an entire section dedicated to keeping your services and data more secure. Additional resources are available, such as a very good book from Apress, Pro PHP Security, by Snyder and Southwell, that addresses almost every imaginable security risk and solution.
—CIO Magazine

There is a fundamental fallacy just because the PHP community considers security a priority, the language must, by definition be insecure. This is followed by somehow equating quantity with quality (shall we bring up how many security flaws there are in Drupal again)?

Web security is both really simple and an infinite mass of shit. If you start with the ad hoc approach, it will seem to only be the latter; but, if you take to the time to learn the building blocks which form the language of security principles, then it start to all make sense and become the former.
—me

Really, just like I go to the Java/C++ world to read about design pattern literature, one does well to go to the PHP world to learn about web application security—the discussions and experience are simply more mature there.

Again equating size with security, and with a bad book also!

Apparently, enterprise web servers are powered by gerbils…

Of course, if you resolve every possible security issue through design and programming, you may find that your system is on the slow side—another complaint rendered against PHP.
—CIO Magazine

This assertion should be proved. I’m well known in the PHP community for saying, controversially:

Web security [and privacy] is a luxury, not a necessity. For any of you think good coding, design aesthetic, or web security are important, I have only one word for you: MySpace.
—me

But I’ve never made the claim that adding security has any temporal cost than the time to develop. More to the point, we often say that the tradeoff of security is between security and convenience, not speed. Big difference!

This assertion is especially important because in these corporations, speed may be a deal-killer, but a corporation can deal with programmatic convenience easily by hiring a ton of programmers, system administrators, and the like.

PHP and shell access

First let’s emphasize that the shell is the method of last resort. It is always preferred to access it via extension or separate it into a highly-cohesive, loosely-coupled web service.

PHP offers several functions to interact with the file system…
—CIO Magazine

Factual error: the functions the author mentioned are referring to the operating system, not the file system. PHP has a set of different functions for deal with the file system. Also, all the other scripting languages I know have this functionality.

…but with great power comes great responsibility
—CIO Magazine

Apparently, Enterprise web application development is built on science fiction platitudes.

So my question is: if CIO Magazine is Uncle Ben, does that make me Spider-Man? And, do I get any rice with that?

[PHP should not be used ]in shell or automated script applications.
—CIO Magazine

This is an apparent contradiction to the above.

Why. Defend. PHP makes for excellent shell scripting as it has extremely strong APIs for database and RPC access as well as a full streams layer allowing for both automated and interactive shell applications.
—commenter on the article

…the burden of proof is on the author of the article. I think what is going on is that the author misread issues developers have with long-lived PHP processes which are dependent on poorly written extensions eventually eating memory resources.

Sometimes a bug really IS a feature

Unlike Perl, PHP has certain timing and memory limitations for a script. If a script exceeds its prescribed time or memory limits, the script dies. You risk having frustrated users and a lot of troubleshooting to do.
—CIO Magazine

The article misses that both properties can be overridden at runtime.

More importantly, this is a feature designed to prevent a runaway process from breaking reliability given in shared-nothing architectures.

This feature is designed to prevent a poorly written shell-script from becoming defunct, as is often seen with other languages and is a purpose-built benefit to the end-user.
—commenter on the article

The default settings for memory and time limits are because they are features, not bugs. Really! 🙂

Scalability

[PHP] isn’t particularly well-suited to large or extremely complex site
…
Each new version of PHP that is released gives hope that PHP will be scalable into enterprise-level applications. So far, it has fallen short of those lofty promises.
…
PHP isn’t Java. PHP 6.0 gets closer to some of the necessary components for true enterprise applications but there’s still work to be done. For large enterprise solutions, PHP makes a great prototyping or feasibility tool, but heavily loaded sites that require thread safety, security and stability should use Java.
—CIO Magazine

We destroyed the myths of thread-safety and security above.

What about scalability and stability? Well it’s adequately defended with this list provided by commenters starting with the #1 traffic’d website on the internet and working our way down:

• Yahoo! (x7)
• Facebook (x9)
• Yahoo! Mail
• Wikipedia (x3)
• Flickr
• Digg
• Friendster (x2)
• Technorati
• some banks in Europe
• CIO magazine itself (x3)

PHP is not only capable for enterprise use, it is being used by the largest enterprises in the industry. I would recommend PHP as the language for all manners of web application development ‚ and this capability is reflected in its adoption rate.
—commenter on the article

I’ve said before that the fact that other websites not written in PHP shows that the web problem is not that hard.

PHP, Java, Ruby, .NET, Python have all proven to be very capable web app development languages. Sure, some have advantages in this respect or that respect. But, in the end, developer skill is an order of a magnitude more important.
—Rocka commenting on the artcile

On the other hand, I challenge the author to come up of a comparable list for large-scale, scalable websites written in any other language. Why not? Because it can’t be done. That’s why I don’t even bother with that argument.

Realize that this reality means that the null hypothesis should be that PHP is de facto scalable and stable for any large scale web application out there—far beyond an “enterprise-level” web application:

If you are going to make a statement like PHP isn’t Enterprise ready, then you better back it up with some proof, or a good reason why.
—PAS comments on the article

The burden of proof is that any other language can be as scalable.

It isn’t the language, it’s the architecture

Of course, in the PHP development world, we made up this aphorism to express the reality that it isn’t about the language, but the framework:

Languages don’t scale you idiot, architectures do.
—comment on the article, and many other people, most famously, Cal Henderson, Director of Engineering on Flickr and author of this book.

Or, more specifically:

It seems to me that most of the issues you point out are architectural and implementation issues. Such issues may be manifested regardless of the language selected. A poorly designed system is, a poorly designed system — regardless of what technologies were selected for implementation. Poor implementation will cause any project to have problems regardless of size.
—matt commenting on the article

Scalability is a vastly complex subject and involves many different elements from the networking, hardware and software platform levels. That’s before you’ve even thought about designing a software system or looked at writing a single line of code. As anyone who has ever done any serious web programming will know, scaling [out] will often be more about the web server or more likely the database server. I don’t think I’ve ever come across a case of where a system could not scale because of the scripting language used. That’s just nonsense.
—Choppsta commenting on the article

Threading/Scalability, these things require skill. Changing languages and platforms is not going to give you scalability magic.
—Paul commenting on the article

…keep PHP in the closet

Perhaps, the most offensive part of the admonishment about PHP is a rapid prototyping tool is the implication that the language is a toy.

I feel a bit offended by the way the author describes PHP as being a “kiddy” language.
—Michelangelo van Dam commenting on the article

The reason this is irresponsible can be seen with the following use case:

My only worry with this article is that some naive IT managers may actually believe these completely unfounded claims. Lets hope they read as far as the commments which seem to be pretty conclusive on what the major opinion is.
—Choppsta commenting on the article

To all people like the author who propagate this myth of superiority, I have to say, “Damn you, erotic furries!”

Parting shot

The article ends with…

PHP is a worthy and valuable tool for programmers, Web architects and those who like to tinker with something cool.

“PHP” and “cool” in the same sentence? lolpadz. You’d be hard pressed to find a language considered less cool by their own developers. Here is another quoteable of mine:

[Some web framework] is like a rounded rectangle; PHP is like a ball of nails.
…
When I say that PHP is a ball of nails, basically, I mean that PHP is just that: a piece of shit that you just put together—put all the parts together—and when you throw it against something, it fucking sticks.
…
PHP is a very powerful tool, very easy to understand, waiting for [you] to use…to build these amazing complex systems by stringing these simple things that PHP gives us.
—me

Jeff Dickey, in the comments puts it a bit more tactfully:

PHP 5 brings a good-enough object and interface model, non-perl-like clarity and obviousness of approach, and an architecture that lends itself readily to easily scalable applications (unlike, say, Rails). Yes, PHP does require you to know what you’re doing if you are to do it well, but I happen to think of that as an advantage. It also, somewhat regrettably, allows one to develop absolute spit spaghetti code…

PHP shouldn’t be the only tool a self-styled professional-level developer (or even a serious amateur) has in his toolbox, but it has earned its success through shipped code that works, rather than geek buzz (perl,Rails) or marketing budgets (Java). That, in and of itself, should recommend it highly.

And there it is…has been for the last ten years: PHP the server-side web scripting language, unchallenged and undefeated.

…Until Microsoft buys us out. 😀

[Continued in Part 4: Time to set my phasers on “kill”]