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. Reasons for why PHP should not be used in enterprise fail you.
4. Time to set my phasers on “kill” <——THIS POST. 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.

I received this e-mail from someone at Zend:

After the latest tempest in a teacup with CIO Magazine, I am left with the question I always have and I want to ask it of each of you.

We see PHP being used in everything from inTicketing to FaceBook to Wikipedia. These are all “large scale” application but obviously the business community at large defines “enterprise” different from “large scale.” So I’m writing a bunch of you asking the same question. Every person receiving this email is in some way connected to PHP but many of you are not developers. I really want a broad spectrum of answers.

“What exactly is ‘enterprise’ and what does PHP need to be ‘enterprise-ready?’”

Oh yeah, bitches, The kid gloves are off and it’s time for that can o tychay! (Don’t worry, Cal, I already picked on you.) Time to pick on the my favorite punching back of all time!

Enterprise Web Application Development

[Why Enterprise Scalability is Science Fiction after the jump.]

This is a work in progress. I have to get some work done today and won’t get to the rest of this until this evening, but I thought I’d give you the outline. Please note the TODO == unfinished. I could use some help. 😉

Enterprise…putting the E in Ego

The whole thing would be comedy if it wasn’t so tragic. These arguments have been hashed over for eight years now, it’s tired. I’ve been holding back on a rant, but two and half years is enough time:

What sort of loser came up with the term “enterprise” anyway? No doubt it was some hapless biz-marketing closet trekkie geek. But this rant will be left for another day.
—me

That rant is today, so prepare to be served, Mr. Biz-Marketing Closet Trekkie Geek. I know the Prime Directive states that I shouldn’t interfere with the internal affairs of primitive cultures like enterprise Java and Ruby application development. And, I should stop right here and jump to the next article. But like almost every Star Fleet captain, I’ll simply ignore the directive when it’s convenient… like now.

Besides while these “enterprise” developers and journalists have “had the com” for this decade, they haven’t said anything cogent or responded honestly to any intelligent counterpoint regarding web development. I don’t think they’re going to hear me anyway:

Everyone in enterprise IT believes they’re Captain James Tiberius Kirk and they know how to win the Kobayahi Maru. What they don’t realize, is that it’s a no-win scenario because it’s coded in Java/J2EE.

I can pretty much say anything I want…

So might as well as start with the truth…

“Enterprise” is a science fiction fantasy

Keeping with the sinking ship theme of the USS CIO Magazine, perhaps this whole “enterprise” field really thinks they’re captain’s of a starship.

What is a CIO anyway? I mean, in the tech world, I’ve met a lot of CEOs and CTOs but not yet a CIO:

I think William Shatner sings beautifully also—really missing those Priceline commercials.

I guess CIOs is like CTOs for companies that don’t value technology.

Okay, that was a bit harsh. But let’s stop for a second and ask us who calls this “enterprise?” If I went up the the CEO of Walmart or General Motors or Bank of America and asked, “Are you an ‘enterprise’?” would they say:

• “Yep! Hey do you like Kirk or do you like Picard?” or,
• No, you trekkie freak, we’re a [corporation/auto company/bank]. Someone get security.

These people pulled a reference to Star Trek out of their ass, apply the adjective to everything from “enterprise scalability” to “enterprise IT” to “enterprise business” where it holds us nerds in judgement like the Sword of Damocles.

This “Enterprise” stuff really is Sci Fi Fantasy.

You feelin’ me?

Enterprise “scalability for REAL”

[[[TODO: NETREK IMAGE: Cluefullness, the final frontier]]]

[[[TODO: yahoo’s numbers, facebooks numbers. Real performance]]]

[[[TODO: most enterprise apps advocate database independence in any area where they can spec the database. If performance were an issue…]]]

[[[TODO: Eric Gamma’s enterprise application. Going to JavaOne and asking about javascript frameworks]]]

[[[TODO: Here 100% of expenses and 100% of revenue is IT, there, a smaller percentage of expenses and 0% of revenue (it’s just a cost). Here 10% inefficiency in 100% of the business, there 10% inefficiency in 100% of business. Common sense: when you application doesn’t have to be tested in the marketplace and when it isn’t exactly mission critical then it’s probably not going to work all that well.]]]

[[[TODO: conclusion: it really is marketdroid speak. “enterprise scalability” oxymoron/closet trekky]]]

I’m curious to know how the author defines “scalable into enterprise-level applications” or what he thinks it means to be an “enterprise-ready language” or what constitutes a “large enterprise solution”. Sounds like a bunch of corporate speak for costing a lot of money and having fancy product names.
—Ryan commenting on the article

I think the main problem around any discussion like this is about how your define the terms “enterprise” and “scalability”. In this case the author has just used the word “enterprise” because it’s a buzzword he’s heard banded around on some blogs that he plagerised but didn’t really understand.
—Choppsta commenting on the article

REAL scalability in enterprise

[[[TODO: I’ll be honest with you, THIS is pretty much the only reason I watched Star Trek.]]]

[[[TODO: travel search: lookers vs. bookers.]]]

[[[TODO: real vs. realtime
– memcache vs. coherence (sidecache vs. readthrough)
– web vs. backend
– real requirements
– don’t want to hear this.]]]

[[[TODO: Where PHP is weak. this performance. back end. ]]]

Facebook is a good example of scalability, but it’s ‘just a social network’. That’s not an enterprise application in terms of business logic complexity. I would be more convinced of enterprise readyness if the banks of this world would build their stuff in PHP. (some are, by the way)
—Ivo Jansch commenting on the article

[[[TODO: caveate: 1-2 million lines of code.]]]

[[[TODO: Do we need the same language in web and back end? tie them in = bad enterprise architecture]]]

The advantage of PHP is by the way that it plays nice with most of the other languages. People often call it a “glue language” because of that.
—Ivo Jansch commenting on the article

[[[TODO: we don’t use “just PHP” at Tagged. Significant parts in Java.
But look at enterprise, what is this obsession with 100% pure Java? Why is Rails my bitch? Because they do everything in Rails]]]

What REALLY scales in enterprise

[[[TODO:
Graphic: blender homogenized java developer.
A J2EE coder writes “5 good lines of code a day” (but they’re really good lines ;-))
All java programmers become equally bad when programming j2ee]]]

[[[TODO: programers are the red shirts of the enterprise world—and no, you aren’t scotty]]]

[[[TODO: code complete, software as construction, ISO9001 process]]]

[[[TODO: This is why php is “bad” for enterprise. Replace a PHP coder, with another PHP coder? Nope! Lose 10 J2EE coders, know exactly how many to replace them with.]]]

What is enterprise scalability really about? Scaling incompetence.

This post… in moron form

Well maybe we’ll see more PHP in enterprise. It’s certainly efficient at the web:

And here in Europe we see PHP entering large enterprises, financial institutes, hospitals and even governments. I see more industries will adopt PHP in the nearby future.
—Michelangelo van Dam commenting on the article

But just in case CIO Magazine is right and CIO’s are preschoolers who can’t make any decision without a powerpoint presentation, here is a summary of this rant in bulletted form:

PHP strengths

• Proven success on the largest, busiesst sites on the internet.
• Ubiquity of knowledge, experience, talent, and tools.
• Simple, non-Perl-like clarity in the code.
• Shared-nothing approach lends itself easily to scalable architectures.
• Plays nice with other languages, systems, and applications.

PHP weaknesses

• To do it well requires a lot of experience
• Competence is across the board leading to a lack of programmatic homogenaeity.
• Language invites ad-hoc architecture and spaghetti code.
• Language is not amenable in any way to a Not Invented Here philosophy. This approach requires that dependent services and applications will need to be, installed, configured, and maintained operationally

When to use PHP

• To make a website, especially where the upper-bound horizontal scalability needs are undetermined.
• To install and maintain a simple web application that is, or is simply mappable to, a solved problem: a blog, wiki, forum, CMS, etc.
• In a company where the Web business represents 100% of your company’s revenue.

PHP is not best for:

• For non-web application or long-lived processes.
• For back-end systems involving threading, complex business logic, or high performance.
• For Intranet verticals with predetermined web performance, scalability, and usage.
• When you need an ego boost—to feel superior to another because of your programming language.
• If you expect to make ludicrous dollars by overcharging on consulting.
• When you think that programmers are, and should be interchangeable and replaceable quantities.
• When you want to keep all your incompetent IT programmers employed.

[Finished in Part 5:Defensing the indefensible.]