I have heared that PHP is not good for large websites althogh I do not know what is the meaning of large websites in this case, is it something like Facebook for example? Any way, is it true that PHP does scale with large websites?
PHP is as scalable as the developer is proficient.
Languages, libraries and frameworks don't scale. Architectures do.
Yes, maybe not as inherently as some others (I'm a PHP developer).
http://swik.net/PHP/Major+Sites+that+use+PHP
Facebook is the biggest example, but there are many other ones as well.
I'm going to differ with my counterparts here. As a language, nothing about PHP is built for scalability. Any language can be extended for that, and PHP has far more than its fair share of tools to do it, but as far as built-in tools to support that need, it has none.
Which is exactly what makes it a great choice.
You see, with the lack of built-in high-level web tools, it allows others to built unique solutions to the problems. Just about every major advancement in other languages has been duplicated for PHP. There is not a single tool out there in some other language that isn't matched or beat by something in PHP.
And after all that, those built-in limitations help foster good development practices and security-conscious designs. It forces we devs to learn the theory behind the techniques we apply and cuts-down on the misapplication of those principals.
Anyway. /lovemaking-with-php
PHP is fairly scalable, and certain frameworks such as Zend increase the likelihood of successful scalability.
The biggest obstacle to scalability in PHP has less to do with the language or its framework and more to do with programming and system architecture in general. Developing a good, scalable system is difficult even for the masters.
A programming language cannot always be pinpointed as THE culprit in problems related to performance. How it's used and what environment it's running in should be considered and must go thru any honest-to-goodness performance audit. PHP is definitely scalable, but the more important things you should consider: application efficiency, disk I/O, bandwidth management, etc. You may have the perfect high-traffic capable application, but try running it on an old PC or a dial-up modem.
It depends on your application architecture not programming languages. If your architecture and design is optimised your application will perform very well on large scale. And also depends on your servers.
I was surprised to learn today that PHP is used widely in high-traffic websites.
I always thought that PHP is not strong in terms of performance, being a dynamic, scripting language (e.g. compared to statically typed, compiled language like C/Java/C# etc.).
So how come it performs so well?
What you'll usually find is that it's not as slow as you think. The reason a lot of sites are slow is because the hosts are overloaded.
But one primary benefit of PHP over a compiled language is ease of maintenance. Because PHP is designed from the ground up for HTTP traffic, there's less to build than with most other compiled languages. Plus, merging in changes becomes easier as you don't need to recompile and restart the server (as you would with a compiled binary)...
I've done a considerable amount of benchmarks on both, and for anywhere under about 50k requests per second (based upon my numbers) there really isn't a significant gain to using a compiled binary (FastCGI). Sure, it's a little faster using compiled C, but unless you're talking Facebook level traffic, that's not really going to mean significant $$$. And it's definitely not going to offset the relatively rapid rate of development that PHP will afford in comparison to using C (which more than likely will require many times the code since it's not memory managed)...
PHP, if properly written can be quite scalable. The limiting factors are typically in your database engine. And that's going to be a common factor no matter what technology you use...
Java deployments in a big enterprise setting are a mess...fighting with builds and code that might not compile for the slightest little things. Also, PHP runs on a fairly simple setup server-wise, not the bulky code that is Weblogic (or others), so others are right in that it's low cost to develop and cheap to deploy on several different machines. It certainly didn't help that I was soured by working in a large, VERY inefficient corporate setting while doing Java....
I wouldn't say that PHP developers are cheaper per se (I make more now as a PHP developer than I did as a Java UI developer) but I do know that my last employer paid me for a not-insignificant amount of time spent configuring, deploying, compiling, etc that is not required in PHP. We're talking probably one day/week of related configuration fussing due to new branch roll outs or release-related configurations. So, the extra I'm paid now is made up for by a significant amount more code that I'm able to work through each week.
PHP is certainly being helped by the fact that MySQL and Postgres (to a smaller extent) have become so much more powerful. They're not directly linked, but having that as a common pairing just sweetens the deal for those making decisions.
It doesn't really perform "so well", just well enough to be used. Keep in mind, though, that Java and C#.NET are also run as bytecode inside a VM. PHP, with tools such as Zend Optimizer, can also skip the compilation step and run as bytecode.
PHP will not run as fast as native, compiled C code, but websites such as Facebook compile PHP to C++ to make it run faster (see HipHop-PHP).
Most websites have performance bottle necks when querying a database etc. The amount of time the script spends executing is usually small compared to this. Using things like libmemcached can help mitigate this.
Many sites started as low-traffic sites. Once you have your PHP website running and suddenly you have to handle much higher traffic, it's cheaper just to buy more servers than to rewrite your app from PHP to something else. Moreover there are tools that improve PHP performance.
Also note, that there are other factors: database, caching strategy which affect performance more than PHP itself.
It doesn't, which is why there are projects like HipHop, but dynamic languages are often faster to develop in, and hardware is cheaper than developers.
In my opinion the stateless nature of PHP is the most important factor to it's scalability. It's been a while since I've done any web work with Java/ASP.NET, but I recall that both technologies have a central application "engine" that all requests are piped through. That's great, because information and state can be shared between instances, and a lot of bootstrapping (reading configuration files, connecting to databases, etc) can be done once, and then shared among instances. It's bad though because that central "engine" itself becomes a bottleneck for the whole application.
The lack of a central engine in PHP also means scaling your application is usually a simple matter of adding another web server to your rig (although scaling the database along with it is more complicated). I imagine scaling a Java/ASP.NET application is a good deal more complicated, and they reach a saturation point where adding more hardware gives less of a boost each time.
I'm a C# programmer and I love the language. I think it's the best thing since sliced bread. Recently I have become real interested in creating a website that offers jobs and allows companies to post jobs for people to navigate through.
This is going to be a nationwide site only, no international connections.
I'm somewhat familiar with ASP.NET (I've used it before for a much smaller pet project) but I wouldn't say I'm more than a
Newb - Journeyman - Novice -
Experienced - Expert
I have absolutely zero experience hosting a website or even registering a domain. I'm familiar with HTML and making applications in XAML for WPF has given me a much easier time understand things that laid out in markup.
Is ASP.NET hosting expensive? Is PHP cheaper? I just need a little guidance. :)
Should I use ASP.NET or PHP?
I'm a PHP programmer and love the language, but with your background, I would absolutely say ASP.NET. PHP hosting tends to be cheaper and more available overall because it's usually Linux based and thus comes with no License fees, but there are good and affordable hosting options for Windows/ASP, too. And who cares if you pay a few dollars more, what you save in man hours will easily be worth it.
Don't forget that PHP usually runs on a LAMP stack, so for anything a bit bigger you will need to gain at least some knowledge of the conventions and quirks of the Linux world, Apache, and maybe MYSQL, too. If you're looking to broaden your horizon, that's certainly a great way to learn new stuff. If you want to get a job done, I'd say stick with what you know.
PHP is cheaper than ASP.Net, specially if you need multiple boxes (servers).
However I would say go with ASP.Net, you'll have less trouble than trying to pick up on PHP.
I have built a website in Drupal. I'm a C# noob and I would have wanted to build the site from the ground but I am not really familiar with security architecture and stuff. If you want to hone your skills in C# and ASP.NET, I'd say go for it. Registering a domain is basic. Building a website in a hosted environment is a good exercise.
Do not worry much about how much you will spend on this project (Host expenses, domain registration, etc). Just think that this goes to your professional portfolio. You can reference this as a tech work. Plus the experience in developing and building the actual site is priceless.
Just curious, but have you thought about using Mono? It's very nice and capable. The newer versions are much easier to install get running properly than before.
I don't know if you plan on using a virtual host or dedicated host or what but the route I initially took was to go to serveraday.com and get a dedicated server and then install Mono and then install my ASP.NET apps. If you are patient you can get a dedicated server from serveraday.com for $200 to $250 a year if you prepay the full year in advance.
I had little to no problems with compatability. It was actually pretty amazing how well the apps worked when going from developed in Visual Studio to being run by Mono.
According to your experience in programming, I would suggest using .Net. It will be easier to come up with a product that looks nice. All this because ASP.Net already has themes and Visual Studio is very user friendly, if you use Microsoft tools. However, learning PHP will get you more into the roots of HTML, JavaScript, HTTP, etc. It will normally be more work than using .Net, but at the end it make you a better programmer.
One thing to consider beyond just hosting is the ability to find talent to help you work on your site.
This is completely anecdotal. I have no stats to back this up, but it always seems to me that there are more PHP developers out there than ASP.NET. My theory has been because of the lower learning costs of PHP. I recently had three experiences to confirm this:
1) A close friend of mine is a tech recruiter in San Diego. He posted a .NET job mid 2009 and couldn't find a single qualified bite for five months.
2) I consult for an early-stage startup. A year ago, they completely converted from ASP.NET to PHP because they simply couldn't find anyone to hire.
3) It's uncommon to find a .NET job on Craigslist where I am in Austin, however I've been watching a particular one for the later half of 2009. This was for an online retailer. They kept reposting this position every two weeks or so, and the pay was very average for this market. If I recall, they stopped around November/December, and I thought they finally filled the position. At the beginning of this month, they reposted the position, but this time it was for a PHP developer who was familiar with .NET technologies.
Again, take this for what it's worth. This is just my limited observations. People will say low barrier to entry = bad coders. I don't buy that. The worst app I've ever supported was a classic ASP app. Low barriers to entry just increases the size of the talent pool. You'll have more bad coders, but you'll also have more good coders, too.
I don't find ASP.NET hosting much more expensive. The hosting company I use even throws a MS SQL Server database (most places charge $10/month for MS SQL Server database) in for free and allows PHP hosting and .NET hosting in the same account.
Check them out. They are pretty good.
Reliable
I would go with what you rather program with. I prefer to use ASP.NET so the little bit of price difference is not worth it for me to switch to PHP.
I have an idea for a website which i would like to run with. My background has always been in the microsoft products, originally coming up from a VB6/ASP to C# and ASP.Net webforms. I love the new asp.net MVC architecture but am worried if my site takes off and i have to scale it, i will be stuck with exhorbitant hosting fees.
Im considering using ASP.NET MVC with mono but am wondering whether i shouldnt just bite the bullet and switch to php with a framework like Zend. I would rather stick with asp.net MVC using mono and running on a linux box, but all the Garbage Collection issues with Mono worry me. My question is has anyone used it and scaled it for web developent or should i throw in the towel and join the LAMP ranks? Any serious suggestions without the fanboy comments on either side of the fence would be much appreciated.
Not sure where people get the idea that windows hosting is hideously expensive. Especially once you get to the point where you need dedicated facilities, at which point the expenses of the bandwidth, power and monitoring take care of any licensing fees you'd need to worry about.
Stick with technology that suits you the best, in which you are most productive. Don't switch just because of possible issues some day, LAMP for sure has it's own problems.
If your web site has so much visitors that you must scale to one or several dedicated servers, then you should have money for licenses, IMHO. Shared hosting on win is aslo cheap, and with speed of win server 2008+mvc, you can be several times faster than LAMP, so hw costs are lower.
If you're worried about costs, Microsoft has a program to help startups - the BizSpark program gives you an MSDN subscription as well as production licenses for Windows Server and SQL Server. And if your site really takes off you'll need a dedicated box or a VPS. If you are renting a box (not colo) hosting on Windows is only slightly more expensive than Linux - and some on some providers Windows is not more expensive at all.
With that said, I do .net during the day and build my side projects on Rails.
Is the LAMP (Linux, Apache, MySQL, PHP / Ruby / Python) stack appropriate for Enterprise use?
To be clear, by "Enterprise", I mean a large or very large company, where security, robustness, availability of skill sets, Total Cost of Ownership (TCO), scalability, and availability of tools are key considerations. Said another way, a company that looks for external adoption of frameworks / architecture - Something ubiquitous will be seen as more "valid" than something exotic / esoteric in this kind of environment.
I've seen use cases where Oracle, IBM, and Sun have implemented systems on the LAMP stack for various Enterprises. I've also seen examples where websites like yellowpages.com (Ruby on rails) and Facebook (php) are built on it. However, none of these examples are exactly what I'm looking for.
I'm really trying to find examples where it is an Enterprise standard at a very large bank (I.e., Citigroup), Telecom company (I.e., AT&T), or manufacturer (I.e., Proctor and Gamble). Just to be clear, I'm not looking for an example where it's used in a limited sense (Like at JPMorgan Chase), but where it's a core platform for systems like CRM, manufacturing systems, or HR management, as well as for internal and external websites.
The perception I've seen so far is that applications built on the LAMP stack perform slower and are less flexible. Some of the arguments I've heard are:
Linux is seen as not as well supported as Unix, Solaris, or Windows Servers.
Apache is harder to configure and maintain than web servers like BEA WebLogic or IIS.
MySQL is a "not ready for prime time" DB for hobbyists, and not a competitor for SQL Server or Oracle (Although PostgreSQL seems to have a reputation for being more robust).
PHP / Ruby on rails are optimized for CRUD (Create, Read, Update and Delete operations). Although this is an advantage when building CRUD-intensive web aplications, both perform slower than Java/Java EE or C# (which are both common Enterprise standards). Furthermore, a lot of applications and systems (like manufacturing systems) have a lot of non-CRUD functionality that may be harder to build with PHP or Ruby, or even Python.
Can anyone please provide arguments to support or refute the idea of the LAMP stack being appropriate for the Enterprise?
Thanks!
KA
UPDATE: Some times the LAMP Stack is Appropriate for Enterprise Use: Externally-Facing Blogs
"but where it's a core platform for systems like CRM and HR, as well as for internal and external websites"
First, find a LAMP CRM or HR application.
Then find a customer for the LAMP CRM or HR application.
Sadly, there aren't a lot of examples of item 1. Therefore, your case is proven. It can't be used for enterprise applications because -- currently -- there aren't any of the applications you call "enterprise".
Your other points, however, are very interesting.
Linux is seen as not as well supported as Unix, Solaris, or Windows Servers. I think Red Hat would object strongly to this. Give them a call. I think they'll make a very persuasive sales pitch. Read their success stories.
Apache is harder to configure and maintain than web servers like BEA WebLogic or IIS. By whom? Apache web site managers? Or IIS web site managers? This is entirely subjective.
MySQL is a "not ready for prime time" DB. Take it up with Sun Microsystems. I think they'd object strongly to this. Give them a call. I think they'll make a very persuasive sales pitch. Read their success stories.
PHP / Ruby on rails are optimized for CRUD, and both are slowly performing. Could be true. Java and Python might be faster. PHP and Ruby aren't the last word in LAMP.
Something ubiquitous will be seen as more "valid" than something exotic / esoteric in this kind of environment.
Although I personally wouldn't recommend PHP due to the many flaws in the language, it's most certainly ubiquitous. With the advent of phusion passenger, Rails support amongst shared-hosting companies is growing pretty quickly too. I give it another year or 2 at most before 90+% of shared-hosting accounts support rails out of the box. If that's not ubiquitous, what is?
Linux is seen as not as well supported as Unix, Solaris, or Windows Servers.
If this bothers you, purchase support from RedHat, or install Solaris and purchase support from Sun. Both of those will give you just as good support as Microsoft is likely to
Apache is harder to configure and maintain than web servers like BEA WebLogic or IIS.
I can't speak for BEA WebLogic, but having configured both Apache, IIS, and Tomcat, Apache is the easiest both to understand, and to find examples and documentation for by a long way.
MySQL is a "not ready for prime time" DB for hobbyists, and not a competitor for SQL Server or Oracle.
Oh really?. You should make it your mission to tell NASA, Google, CERN, Reuters etc that they're all using a hobbyist database that isn't ready for prime-time.
PHP / Ruby on rails are optimized for CRUD, and both perform slower than Java/Java EE or C# (which are both common Enterprise standards).
There are 2 things here:
Optimized for CRUD - This is totally irrelevant.
Rails and some of the python/php frameworks are optimized for CRUD apps. Many of the C#/Java frameworks are also optimized for CRUD apps. However, if the app you're building is a CRUD app (and 99% of web applications are), isn't this a Good Thing?
If you're not building a CRUD app, there are plenty of non-crud-optimized frameworks in ruby/python/php/java/C#. Net win: Nobody (hence it's irrelevant)
Perform slower than Java/C# - This is undoubtedly true, but it also doesn't matter. For a low-traffic site the performance difference isn't going to amount to anything, and for a high-traffic site your bottleneck will be the database, whether it be MySQL, oracle, or whatever.
What you trade-off for all of this is development time.
Once you've used all this advice to convince your boss that you won't lose out on anything by using LAMP, If you crunch the numbers and show your them that it is going to take 6 man-months to build the site in Java, and only 3 to build it in ruby/python then that's really what it comes down to.
If you hire idiots to implement it, C++ & Oracle will fail to scale.
If you hire people who are smart and get things done, PHP & MySQL will scale just fine.
Same argument goes for security & robustness.
Facebook, Digg, portions of Yahoo run on PHP.
Of course, they hire lots of PhD programmers.
Just thought I'd add another website to the list of those that run on LAMP - Wikipedia. Seventh biggest website in the world, written entirely in PHP and runs off MySQL, and they only have two or three paid developers. Of course, they have some assistance from volunteers, but it's not a lot, and it's scaled just fine. Don't know if you'd really call them 'enterprise', but for such a huge and popular website they seem to have done alright for themselves.
Linux is seen as not as well supported
as Unix, Solaris, or Windows Servers.
As others have said above, give Red Hat a call and I'm sure they'll beg to differ. And the amount of support out there for Linux absolutely free is astonishing.
Apache is harder to configure and
maintain than web servers like BEA
WebLogic or IIS.
That depends who you're asking. People who usually administer IIS servers will probably view it this way. People who usually administer Apache won't. It depends on who you hire, and if your stack is LAMP you won't want to be hiring people with no Apache experience anyway.
I just want to add that I've witnessed many times that clients only feel comfortable once they dish out serious $$$ for some solution, even if it makes enterprise integration even harder, despite what arguments you bring to the table.
I think the first criteria should be your team's skill level, comfort level jut to make sure what ever platform decisions are made works well with them. Whatever you decide think of scalability and maintainability of your code. Tools are awesome no matter what stack you choose.
I personally would break it down into 3 stacks-
The Java Stack where you have Solaris or Enterprise Linux like ( RedHat ) with Weblogic/Websphere/Tomcat etc and Java Enterprise along with Hibernate,Spring etc technologies. Most would opt for Oracle as DB.
The Microsoft Stack with some Open Source if needed Win Server - IIS - .net/C# (ASP.net etc) - NHibernate, NUnit (unit testing) etc. Most likely you would want to use SQL Server as DB
None of the above stack with Enterprise Linux running a whole buffet of open source stuff like MySQL (now under Sun's domain so can be looked at seriously), Apache (there are apache gurus out there), Ruby ( not my personal choice)/ PHP (good luck) / Python (I like it because its a mature language). I would advocate python or ruby from the managing code point of view. Maybe for some it could be PHP..i am not into it.
strictly a subjective opinion but I personally find MySQL and to a lesser extent PHP to be a bit of a weakness, but certainly there's plenty of people who disagree and big companies who went LAMP.
I'd prefer to see postgres or even SQLite take chunks out of the MySQL market, and I'd like to see mono or jsp or cocoon based apps more. I guess LAMP is a bit too specific for an umbrella term. :)
Linux/Apache are hardened, lean and each comes with plenty of people(for the right price of course) who will provide support, plenty of useful tools, many at exceptionally high levels of utility which work with them and which have been built upon them.
Not sure about the other two, however. In particular MySQL seems to have taken a strange turn for the worse since their being acquired by Sun, contrary to the posts in this thread suggesting that Sun may be a good influence:
http://www.reddit.com/r/programming/comments/7gb8j/oops_we_did_it_again_mysql_51_released_as_ga_with/
The reason for not finding Enterprise applications built on LAMP is not because they aren't enterprise level but something entirely different in my opinion. A lot of the big players use LAMP or similar--Facebook and MySpace immediately come to mind. So its clearly not an issue of scale and perf.
That said, the reason I find that there aren't any enterprise apps built on LAMP is because of their intrinsic open nature. I don't want to build an actuarial module as a PHP file because anyone can steal the logic. On the other hand if I have a DLL I can retain control. You don't find a lot of 30-trial apps built on PHP for this very reason but it's much easier to achieve that kind of protection with say ASP.NET.
You have some real bad myths in your posting:
JavaEE Myths:
-App Servers easier to configure than apache, nope apache is easier.
-You imply that only JavaEE full solution is enterprise, nope.
CRUD Myths:
-CRUD is slower than JavaEE? WTF? POJO and EJB is using CRUD.
The limiting factor is not crud, its server throughput
There are 3 limiting bottleneck areas no matter what technology even MS..server implementation, persistence layer, and app layer..the technology chosen is not the speed factor as you can exchange advantages in one layer for disadvantages in the other layer.
Fro example we could spee dup Java by using document store instead of normal DB..
Most new Rails implementations use non apache servers that are faster by a factor of 3 to 5 than Apache..even a well tunned Apache server can outperform some javaEE stacks..just ask yahoo as they use Symfony on some of their properties..
I think you will find that many enterprises use Linux servers, often supported by Redhat, Novell or IBM, and that Apache is also commonly used.
But many enterprises tend to use databases like Oracle or IBM DB2 instead of open source offerings - although there are many enterprises that don't really need the kind of power those systems provide and could get away with MySQL or PostgreSQL.
And for the web-server language, I think you can use just about anything. However, if you use Apache it is probably easier to use PHP, Ruby or Python, whereas if you use IIS or Weblogic or Domino it will be easier to do it in Java / C#.
IMO there are no good general arguments against Linux and Apache; You can certainly get enterprise-level support for Linux if you're prepared to pay for it (and a good approximation of it for free if you're willing to play by the community's rules). And Apache is not that hard to configure unless you need its more complex features, which is unlikely in an application server.
You can certainly make a case against MySQL since some of the most important features in regard to data safety have been added only recently. If you're concerned about that, use PostgreSQL instead.
As for the language you write your app in: PHP has definitely proven to be able to run extremely large and complex systems; I'd be more concerned about maintainability than performance. And Ruby on Rails is "optimized for CRUD" only in asmuch as a simple CRUD webapp can be written in nearly no time (literally minutes), but that does not mean it is somehow less suited to more complex apps, just that it will take much more time (still less than with many other languages)
I suppose that large commercial CRM and HR applications might be biased toward delivering large commercial RDBMS products as the foundation for their products. If nothing else they will I'm sure prefer to unite against a common threat.
And they have a harder time justifying license and support fees if they integrate products that don't have them.
My 2c:
Linux: Since kernel 2.6 came out, I would say it is definitelly a high-quality OS. Version 2.4 wasn't quite there and 2.2 was a joke, but 2.6 is really good. Be careful with a choice of distribution, though. In my experience, RedHat/CentOS is very good, and apparently Debian (original, not Ubuntu!) can be set up nicely if you have a good admin. My experience with OpenSUSE was not very good.
Apache: Haven't used it, but I don't see why it would be a problem.
MySQL: This is the weakest point of the stack. I am not going to go into details here - look into comments at reddit.programming if you are interested. Better look at PostgreSQL.
PHP/Perl/Ruby/Python: I have worked with Perl and to a lesser extent with Python. They are probably OK for web-based applications where the bulk of the work is done by the web server and DBMS anyway. However, I do prefer static type system and would rather pick Java/C# for a business application and C++ for system programming.
I would like to suggest that we identify the scalability requirements of Enterprise systems and how they differ compared to Web Applications. Look at some of the most scalable systems like Wikipedia, Flickr, Wordpress, Facebook, MySpace and a host of others. You will see LAMP stack there. I am more of a Python fan (since I feel that the language has a cleaner feel) but I listen to experts like Cal Henderson (Flickr) who wrote a book on scalability talking about how he scaled a bank of MySQL servers.
What are the essential features of an enterprise system?
Support, availability of expertise, stability of the platform/language probably count.
But LAMP has other features like faster development, easier extensibility, lots of available libraries for reuse, several documented stories of scalability, maturing web frameworks.
Here are a couple of pointers to building Scalable systems (I am talking about Web Scale). I always wondered in the light of all this evidence, why the perception of LAMP as not being ready for Enterprise apps keep popping up.
As for Apache, every Netcraft study shows a very different adoption story. By the sheer number of servers, there may be more people with knowledge to configure, tune and extend the web server.
Scalable Web Architectures
Please Look at Market Share of all Servers Aug 1995 to Jan 2009
Linux is used a lot.
Apache and Tomcat are used a lot.
MySQL may be robust now. I'd use PostgreSQL instead. Banks will use Oracle, but there's good support for Java and Tomcat there.
PHP is used a lot, but many big companies would prefer Java.
You're best off arguing for a Linux, (possibly commercially supported version of) Tomcat, Java, Tomcat|Oracle|MSSQL solution, in my opinion.
You'll need a Linux sysadmin, especially as the number of servers ramps up, although I'm sure you can get a part time one in before that time arises. If the company already has Windows sysadmins then arguing for Linux is going to be tough.
I believe it's not that the technology is premature or something which keeps biggies like AT&T to go ahead with a full implementation at enterprise level. These companies have such a big budget for IT spends that the last thing they would have on mind is to spend more on the customization and enhancement required on the open source techs to suit their business needs.
So what they look for (which comes from my consulting experience) is buy and run product pack and don't have to spend more on the research and hack part. Companies which use open source build have developed their own support groups globally to cater to any support demands, which large enterprises are not much willing to do. They need thing done fast and for sure and they can pay.
There are two main issues for large enterprises using LAMP stacks:
TCO: taking into consideration that LAMP basically comes free, enterprises still achieve a lower total cost of operation with other commercial solutions
Supportability: enterprises have no problem paying the extra buck to get around-the-clock professional support from their commercial vendors
Redhat and IBM give full support for Linux, Sun bought MySQL, Yahoo uses Php, numerous companies use a LAMP stack, but many use parts.
I personally don't see Linux as being less well supported than the other OS mentioned; in fact hardware vendors typically DO support Linux over any other OS (except for Windows, which they do generally support quite well provided you use maintream distributions).
Provided you don't use a bizarre flavour (Tip: Just use RHEL or Centos which is its free equivalent), Linux is very well supported.
MySQL may have some shortcomings, but in my opinion it has many strengths; we use it at a large scale in ways not intended, but it still works quite well generally (most of the problems are due to our versions being out of date or badly configured).
What "P" stands for in LAMP is debatable. I feel that PHP is not enterprise-ready, because it has so many individual shortcomings (e.g. poor unicode handling, no namespaces, inconsistent APIs, inconsistent syntax, poor version backwards compatibility, duplicated/obsolete functionality) that they add up to making it difficult to implement a maintainable system.
But given an appropriately experienced team, even if you choose PHP it can be used to make an extremely high quality application.
If it's good enough for Google, trust me, it's good enough for you.