Enterprise PHP

[brainpipe]

We've got a few, actually, they just don't come "out-of-the-box." A lot of people like Phrame, for instance. But I think the lack of true OO support in PHP4 really hinders framework development.

[M. Johansson]

PHP 5 is a lot better, though. Definetly a step in the right direction.

[Dr Livingston]

Lack of true OO PHP4 support ?

Umm... I'd say that what we do have we should be thankful of it and IMO it doesn't actually deter you as a developer that much from developing OO apps etc surely ?

Sure it could be better supported but that's not to say that what is there is inadequate...

[M. Johansson]

Deter and deter...

It's a question about choosing the best solution. If Java, .NET or Python is better for you, you go with it.

[Dr Livingston]

Well that is true although some clients are just not prepared to accept the additional costs and IMO the increased development time of using Java for example, which in all reality is a far more complicated language to develop for than PHP no ?

As developer's we lay down the options; their advantages and dis-advantages; their costs etc and at the end of the day the client chooses and in my area they choose the cheapest option, ie Open Source -> PHP ?

[Jeremy W.]

Yes, but do you know the cost? Do you actually know what's cheaper? Seriously now. Can you, to a 50M$/year company say "PHP is going to be cheaper for you", nevermind, like in brainpipe's case, a 2B$/year company?

It's my job to make decisions that'll last, and, hopefully, decisions that won't be second-guessed every 5 minutes when I leave.

So, would PHP be cheaper than .NET in various situations? Certainly not in all. In fact, I'd hazard a guess that it would only really be cheaper if you already had PHP-ready staff on hand, and if you were already in an xNix environment and if you hadn't already invested in other infrastructure.

That would be my guess as to the situations where you could say "without even looking into it, PHP will likely be cheaper for you". In all the rest of the situations, though, you'd need to do due diligence, and I doubt that most developers even know what that is, nevermind how to do it.

J

[M. Johansson]

Well that is true although some clients are just not prepared to accept the additional costs and IMO the increased development time of using Java for example, which in all reality is a far more complicated language to develop for than PHP no ?

As developer's we lay down the options; their advantages and dis-advantages; their costs etc and at the end of the day the client chooses and in my area they choose the cheapest option, ie Open Source -> PHP ?

Using PHP on an enterprise level requires MORE development time, as you must develop guidelines and framework before you can start. That means it's often more expensive to use it.

Open Source is far from always the cheapest solution, since it often require huge amount of human resources. It does save lots of money if you have lots of servers to deploy it on, though.

[Dr Livingston]

Open Source requires more human resources ? Umm... Yer, I can agree to that point with no problem as there is some truth in that.

As for 50$M ? The average client over hear doesn't even have a profit margin of 5$M per annum, never mind anything else

Very few multi-nationals in the NE over here, bar Aberdeen where you have the Oil And Gas Industry of course and even then their Web requirements are mostly dealt with by big design houses in London/whereever if you see where I'm coming from ?

Companies locally do not understand Frameworks etc etc; They are not really concerned about reaching out to someone surfing the Net over in France or Germany etc - They're more concerned about generating more business locally.

The view I have is the wider Internet community (ie Globally) is of little revelance to them ?

[mgkimsal]

Yes, but do you know the cost? Do you actually know what's cheaper? Seriously now. Can you, to a 50M$/year company say "PHP is going to be cheaper for you", nevermind, like in brainpipe's case, a 2B$/year company?

Certainly.

We did just that with a $1B/year company, and that was after they'd dealt with ASP problems for over a year. They'd brought in an entire team of MS certified people from a much larger consulting company to review/log/test/debug every aspect of the system in place because it was severely underperforming.

After 6 weeks and tens of thousands of dollars just trying to pinpoint the problem, the final report was 'we don't know, but spend more money and we can probably figure it out'.

Yes, the company was grossing about $1B/year, but that doesn't mean that they were willing to put all that billion into this department (though they should have, as it was responsible for the majority of the revenue, but that's a political issue). In fact, after having redone the system in PHP, they were able to find developers who could adjust to the system (and respond to issues) faster than when the sytem was ASP based.

We went from having to maintain 8 servers down to 3, which cut their overall costs down. We got faster response times on the site pages under PHP (without a caching system).

The department we did this for was just that - a deparment, not the entire $1B/year company. Accordingly, they had a budget. The bean counters kept looking for ways to reduce costs, even though they were already pretty low with the original MS/ASP system.

As a % against gross, the entire project's costs were *very* small, and should have been given more funds. But, agains the department budget they were bigger than the company wanted, and any move to cut costs (monthly maintenance, development time, downtime, etc) were entertained.

I know the response to all this will be 'ASP != .NET', but that's all there was at the time. If they had the decision to make *today*, they might not have moved to PHP. But I think they probably would not have cared one way or another. The move to use ASP in the first place was largely one done by an outside consulting company, because this company didn't have a religious tie to one camp or another.

Actually, during our PHP development time, there was another company brought on by another department that had something like 20 full time people doing a Java project which went months and 100's of thousands over budget. It was eventually axed and that dept largely disbanded from what I remember. But that got people's attention, that a large Java project largely failed while our PHP project just kept chugging along.

[mgkimsal]

That would be my guess as to the situations where you could say "without even looking into it, PHP will likely be cheaper for you". In all the rest of the situations, though, you'd need to do due diligence, and I doubt that most developers even know what that is, nevermind how to do it.

That's a problem right there, if you've got 'developers' trying to do 'due diligence' on quoting/speccing a project on their own. 'Developers' should only do such things in concert with business people who can keep things in perspective. Having a coder do that sort of stuff on their own will lead to a bad experience (providing they even get the work at all).

[Jeremy W.]

Dr Livingston, no offence, but it's not up to the company to care about frameworks, etc. It's up to the developer.

And if PHP takes more man hours, that's more money, which affects the bottom line directly.

Michael, you're right, I would say that .NET may have been a better option, but it appears that documentation and developer training may have helped as well.

After all, I have a hard time believing an app written to the exact same standard in PHP vs ASP would perform 200% better and require that much less hardware.

Well done for delivering a great product and great project, and who's to say that PHP wouldn't have been a better choice even if .NET hadn't been around.

My point was that blanket statements like "open source is cheaper" aren't accurate ina corporate environment. In fact, no statement like "x technology is cheaper" will tend to fly, because you need to do your due diligence and actually run the numbers

As far as your last sentence, I'm sure we can both agree it wasn't because of hte technology that the other project went over budget and over time, but because of project management. Well done to your team again!

J

[M. Johansson]

First of all, and most importantly:
ASP was a horrible technology that I would not touch with a long stick, unless I was paid lots and lots of money, and I would be hestitant even then. PHP is much better. I'm so glad ASP is dying.

Now, as for PHP / Java / ASP projects - I cannot imagine that the success of a project falls or stands depending on what language you are using. If a Java project fails, and a PHP project succeeds, or the other way around, I would blame that on (really) bad developers rather than the languages. Some people just suck at what they do.

[coo_t2]

Using PHP on an enterprise level requires MORE development time, as you must develop guidelines and framework before you can start. That means it's often more expensive to use it.

Why would you have to develop a framework when there's a zillion free ones to choose from?
I understand how one company pushing one framework and one set of standards can lead to greater productivity.
But not having that doesn't mean you have to make your own from scratch does it?
It just means you have to decide which ones to use from the ones availble.

--ed

[Jeremy W.]

Ah, so now you need to figure out which framework is best (5-10 hours?), ensure it'll do what you need to (5-10 hours?), install and configure on all the servers (1-5 hours?) and then you have 2 pieces of software you need to maintain:

PHP
Framework

This will result in considerably more work in the long run than just having PHP on it's own.

The above recommendation is PHP's greatest strength and it's greatest weakness: the tendency to install a myriad of extra modules and libraries.

The long-term maintenance of those would have to be an absolute nightmare to any organization.

J

[Jeremy W.]

That's a problem right there, if you've got 'developers' trying to do 'due diligence' on quoting/speccing a project on their own. 'Developers' should only do such things in concert with business people who can keep things in perspective. Having a coder do that sort of stuff on their own will lead to a bad experience (providing they even get the work at all).

Don't worry, I completely agree. My comment was to highlight this very fact. In my experience, especially on these boards, developers feel it is their responsibility to ride the entire project lifecycle.

Realistically, it's rare for a developer to even choose the language, platform, framework and even OS they'd be working on in a given project, as that would be pre-decided before they even heard the project existed, at least at the level we're talking about.

J

[M. Johansson]

It just means you have to decide which ones to use from the ones availble.

You are right, but I would not use "just" in this sentence.

[Mike Borozdin]

Well,

We was talking about PHP, Java, .NET, Zend, Sun, Microsoft, classes, public and private methods, big companies support.

But we forgot that there're such case when company doesn't need a technology (it has no matter what it is, PHP or Java or .NET) but it is interedted in a product. Yes, in product not a technology but in product. They mayn't want to develop any software but they want use or at least to make some changes.

And as we know it's possible to write enterprise level applications with PHP. And they exist. And some of them have versions bundled with Apache, PHP & MySQL, I mean EZ Publish (www.ez.no), for example, they distrubute Linux and Windows bundled versions.

[asterix]

That being said, PHP in the right hands could be a very powerful business tool, especially considering it's licensing fees and initial cost when compared to more "advanced" alternatives.

Not many CIOs are gonna say "gimme 200K less in my budget, thats because we'll use php and save some dosh".

AFAIK PHP does still not do transactions - correct? Until it does, it won't be being used in many enterprises, at least not those run by the same CIOs who always trundle out this bit of *wisdom* to justify huge budgets.

So "Enterprise" has not much to do with the capabailities of an App. server or language, more about how "accepted" it is in business. Frankly, the biggest impediment to PHP are PHP coders. Now don't get me wrong (I code in PHP too), I'm arguing from the CIO point of view. PHP Coder's are still seen as an unwashed horde of freshmen looking to earn some beer money on the side - and there are plenty who still fit that mould. PHP is popular, free and powerful, of course it attracts people who have just learned HTML and are moving up. The CIO nightmare is having inexperienced coders & project managers working on high profile i*net projects, that's just the kind of "business risk", i.e. "personal embarassment risk" that they are never ever gonna take.

Saying "We did this in PHP" still sounds like "We knocked this up in BASIC" or "We had this done on the cheap", which basically are arguments which do not get spoken at board meetings. PHPers need to change that bias against them in order to ultimately get more work / more money from their PHP skills.

Why has MySQL introduced certification? Its because they've realized the same thing that cisco, sun, MS, oracle and the rest realized earlier: the need customers to have faith not just in the technology, but the people implementing the technology. PHP sorely und surely needs one single authorized and accredited group of examinations leading to certification, something like:

Certified PHP Web Site Developer
(DB interaction, installation, setup, troubleshooting, programming, OO programming)

Certified PHP Solutions Architect
Same as above, plus transaction stuff, message queuing, load balancing, requirements analysis, extensions programming and so on.

Then there would at last be a solid foundation on which CIOs could build their trust, and PHP could enter areas where it traditionally has had little chance.

[Jeremy W.]

I love how evil us IT Directors and senior managers are. Only caring about how big our budget is in the scope of things.

[mgkimsal]

Not many CIOs are gonna say "gimme 200K less in my budget, thats because we'll use php and save some dosh".

But many might like to play with other cool stuff with that 200k, or perhaps hire more people so they can have more staff, or whatever. They like to spend - having an extra 200k lets you engage in more spending activity.

AFAIK PHP does still not do transactions - correct? Until it does, it won't be being used in many enterprises, at least not those run by the same CIOs who always trundle out this bit of *wisdom* to justify huge budgets.

PHP has nothing to do with transactions. Those are handled by the database, of which PHP can deal with many.

So "Enterprise" has not much to do with the capabailities of an App. server or language, more about how "accepted" it is in business. Frankly, the biggest impediment to PHP are PHP coders. Now don't get me wrong (I code in PHP too), I'm arguing from the CIO point of view. PHP Coder's are still seen as an unwashed horde of freshmen looking to earn some beer money on the side - and there are plenty who still fit that mould. PHP is popular, free and powerful, of course it attracts people who have just learned HTML and are moving up. The CIO nightmare is having inexperienced coders & project managers working on high profile i*net projects, that's just the kind of "business risk", i.e. "personal embarassment risk" that they are never ever gonna take.

So they'll spend a couple million on an overpriced project that never quites get done, in which time they can move on to another company, and that's OK. But dropping $100k on a PHP prototype which doesn't do everything right on day 1 is an embarrassment they can't live with? (Seen both happen) There need to be some expectations management on both sides of the equation. Also, what happened to companies actually fostering learning and development amongst their staff (perhaps even cultivating some loyalty)? Taking people who are talented but maybe a bit raw and shaping them into 'proper developers'? Maybe it's because most managers aren't very good at that sort of thing...

Saying "We did this in PHP" still sounds like "We knocked this up in BASIC" or "We had this done on the cheap", which basically are arguments which do not get spoken at board meetings. PHPers need to change that bias against them in order to ultimately get more work / more money from their PHP skills.

But part of that 'bias' stems from people thinking that PHP can't do things ('transactions'?). Letting people know that PHP is actually at the heart and center of a billion dollar operation *should* inspire some level of interest or respect from potential adopters, and not automatically make them assume that people were just doing something 'on the cheap'. One of our students came from a large newspaper organization (HUGE in the US, not sure about abroad so much - 100 dailies and about 8 million paid subscribers). About 60% of their content was touched by PHP processes somewhere along the production line. That's not peanuts, and the fact that they were bringing in outside PHP consultants and sending staff to training seemed to confirm their belief in using it long term, and that it wasn't just a 'fad' or a 'band-aid'.

Why has MySQL introduced certification? Its because they've realized the same thing that cisco, sun, MS, oracle and the rest realized earlier: the need customers to have faith not just in the technology, but the people implementing the technology. PHP sorely und surely needs one single authorized and accredited group of examinations leading to certification, something like:

Certified PHP Web Site Developer
(DB interaction, installation, setup, troubleshooting, programming, OO programming)

Certified PHP Solutions Architect
Same as above, plus transaction stuff, message queuing, load balancing, requirements analysis, extensions programming and so on.

Then there would at last be a solid foundation on which CIOs could build their trust, and PHP could enter areas where it traditionally has had little chance.

Biggest problem is WHO does the certification? PHP isn't owned by one corp. We've planned on doing PHP certification, but initial feedback from potential students is that they wanted to only do things 'over the web', which defeats the purpose of 'real' certification (imo). Too many cheaters, etc. Also, the company itself. Although we've been doing training for over 2 years (http://www.tapinternet.com/php/), not many people know about us, and thus 'certification' from us may not hold much weight. But maybe it would? So, until someone can work out a certification process with a large test-taking org, it probably won't happen.

[Selkirk]

PHP has nothing to do with transactions. Those are handled by the database, of which PHP can deal with many.

Transactions don't necessarily have to take place in the database. Take a look at Java Transaction Service, Using CORBA transactions, Microsoft Transaction Server and CICS ("CICS can support over nine hundred thousand concurrent users" yikes!)

Transaction servers are only one piece of the enterprise application puzzle. There are other types of middleware like message oriented middleware, object request brokers and remote procedure calls.

[Karl]

"Why develop a framework when there are free ones already?" - Mainly because a lot of them are very poorly coded, they are hacked together by people in there spare time who don't have experience in developing code for the enterprise. Of course not all are like that, but the majority are.

I'm with Jeremy on the fact that one of the greatest weaknesses of PHP is the myriad of modules, take XSL for example, not a commonly installed module - now that can be a big problem for deployment (OK, not for large scale systems as you usually have control over server apps etc.), now Java on the other hand, if I had a problem of a set of classes I needed to use for XSL not being available then I'd just drop the JAR into the classpath and away we go, simple as that.

[asterix]

But many might like to play with other cool stuff with that 200k, or perhaps hire more people so they can have more staff, or whatever. They like to spend - having an extra 200k lets you engage in more spending activity.

Spend? No, I don't think so (and being a CIO I am in a position to judge They like Big Budgets. Give me a Budget of 2M, and I utilize 1.8M, then I save the company 10%, and use that argument to prove how cool I am & can be entrusted with more money . But thats a difficult game and a different topic.

PHP has nothing to do with transactions. Those are handled by the database, of which PHP can deal with many.

Thats the problem. PHP doesn't AFAIK do transactions, so arguing that some other layer (vendor) should do it is shooting yourself in the foot. There are many good reasons why databases should not manage business transactions. Ever heard of two-phase commit? There is no reason why transactions shouldn't be offered by a programming language, unless you concede that the language in question is not and never will be targeted at that market. Which is why IMHO MySQL now can support transactions.

Also, what happened to companies actually fostering learning and development amongst their staff (perhaps even cultivating some loyalty)? Taking people who are talented but maybe a bit raw and shaping them into 'proper developers'? Maybe it's because most managers aren't very good at that sort of thing...

That's missing the point. Mentoring / Fostering / Developing PHP programmers to where exactly? With every other major web dev. language you can put a certifcate under your activities. Then you can measure success or lack of it. This is *exactly* the kind of thing managers should be good at.

Letting people know that PHP is actually at the heart and center of a billion dollar operation *should* inspire some level of interest or respect from potential adopters

Maybe, yes. But then again, most companies are not dot coms, innovating is what they do in the design rooms, not in their programmng pens.

That's not peanuts, and the fact that they were bringing in outside PHP consultants and sending staff to training seemed to confirm their belief in using it long term, and that it wasn't just a 'fad' or a 'band-aid'.

I agree and applaud, really, that is great for the Web, PHP and eventually everybody. But I would like to see these outlyers become the median.

Biggest problem is WHO does the certification? PHP isn't owned by one corp.

Well, for a certificationn to be recognized and gain rapid acceptance it must be from an accredited certifier. And who does the accreditation? As you say, nobody owns PHP, so nobody can accredit a certification or training vendor.

You only need the whole shebang if you believe that PHP should pave the way to web domination. I don't hold that view, I believe that if Rasmus or Zend or whoever started accredition schemes, then part of the appeal of PHP would die immediately. But then I accept that PHP will be at the bottom of the web language food chain, something like PHP -> Coldfusion -> ASP -> PERL -> ASP.NET -> J2EE. (And that is soleley based on the hourly rate of programmers in those languages, not the capabilities of the language).

So, to recap, PHP is not an enterprise technology (language). But who wants it to be one anyway? Isn't the top end of the market crowded anyway?

[HarryF]

A few things.

"Why develop a framework when there are free ones already?" - Mainly because a lot of them are very poorly coded, they are hacked together by people in there spare time who don't have experience in developing code for the enterprise. Of course not all are like that, but the majority are.

But the "not all" includes eZ publish (which we build our apps on at work), Krysalis and Logi Create (which I have no first hand experience of). All of which are most definately are coded by experienced developers, have commercial faces and for which support can be purchased.

I'm with Jeremy on the fact that one of the greatest weaknesses of PHP is the myriad of modules, take XSL for example, not a commonly installed module - now that can be a big problem for deployment (OK, not for large scale systems as you usually have control over server apps etc.), now Java on the other hand, if I had a problem of a set of classes I needed to use for XSL not being available then I'd just drop the JAR into the classpath and away we go, simple as that.

As we're talking enterprise, the necessary expertise / platform should not be an issue.

Yes I see your point that Java has better standards etc. But is Java perfect? Perhaps far from it - many Java projects still fail badly although there's more than enough expertise around to prevent it.

But in this web enviroment, I still believe no one has all the right answers so choice is most definately a good thing - with PHP it's tough to decide but the end result may be a better match for your needs. eZ publish (2.x), for example, has the feel of an app that was designed by C++ coders while others like php.MVC will most definately appeal to Java coders. The prerequisite though is you have some idea of what you're doing to be able to choose in the first place...

Adding to this the question of support, are you really better off with commercial software?

Take ASP 3.0 for example - it now has no future. Given MS's record on Windows upgrades, it might be reasonable to expect they'll cut support for it at some point as well.

How do users feel about that? Companies effectively need to re-train their staff (many having originally had a background in HTML), how to step up from VBScript to a platform which is trying to compete with Java. Now that we've got past the wow effect of .NET, I wonder how many companies using ASP 3.0 are considering PHP as their future?

Overall what seems to be the conclusion of this discussion is that PHP is only "enterprise" if there's expert developers around to work with it.

But here's a question - how many web developers do you know that understand how HTTP 1.0 Cache Headers work? What about all the stuff HTTP 1.1 adds like ETags? Not knowing the answer could be costing you alot in bandwidth and server load. For a high traffic site this can be critical.

Don't look to ASP.NET or Java to solve the problem for you, by providing a friendly class to wrap the problem beyond the developers need to know about it.

Yes the @OutputControl page directive makes sending the correct HTTP headers easier but implementing HTTP client side caching successfully requires some element of building it into the application, it being the only thing that "understands" the age of the content it renders.

Web developers should know how HTTP (1.0 at least) caching works. Knowledge is prerequisite no matter what tools you're working with.

Providing the guys who work in data warehousing, who develop reports with VisualBasic, with a framework that allows them to knock up web applications is not a recipe for enterprise web sites IMO.

[hillsy]

Just a couple of quick thoughts...

There are plenty of dumb enterprises out there. I know, I work for one. Our purchasing decisons in the web/intranet area leave me scratching my head a lot of the time - not to mention making my job harder. Point is, enterprises don't always know what's good for them. They should, but then some middle manager comes along and gets in a p*$$ing contest with another one, and before you know it process has gone out the window. In our case, shifting to an all-PHP environment would solve a lot of problems. ASP.Net would solve even more but we're in short-term cost-cutting mode right now which precludes upgrading our servers from NT4. So instead, we soldier on with a weird mix of ASP, ColdFusion Express (yes you heard right), ColdFusion 4.5, Plumtree, Domino and Zope

I know this isn't how a well-run business operates, but I also know I'm far from alone.

Harry - good point about future supportability. I recently applied for a job at a very large public sector organisation that is standardising on PHP to achieve a level of vendor-independence. Good example of choosing PHP for the right reasons (I guess Java was the other candidate).