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.
Related
Compiled code of ASP NET will perform much faster than PHP. Does that mean ASP NET need less server than PHP to perform equivalent application? Thus, ASP NET development able to save cost in hardware?
Any widely used programming language will be able to perform faster than PHP. Nobody is using PHP because it is fast.
And unless you are building something that requires tons of resources, speed is definitely not your primary issue, because even a small increase in development costs will dwarf what you'd save hardware wise.
Here is a good article outlining your concerns. I have stripped out some of the points, but the following should answer your questions.
I. Scalability and Ease of Maintenance
Scalability and ease of maintenance have nothing to do with whether you select PHP or ASP.net platform. Web Application scalability and ease of maintenance primarily depend on:
Programmers' experience
Using the best programming practices
Using a solid programming framework
Following programming guidelines and standards
II. Performance and Speed
There has been much debate about this subject and most of the debates have been biased and have been tailored to promote one of the programming languages instead of informing the audience.
However, if the programming language needs to perform enormous tasks similar to the kind that sites such as Google or Yahoo do daily, then there should be a lot of consideration in selecting a very fast programming language for required enormous tasks — that is why Google and Yahoo use several programming languages (mostly open source), each selected to handle the tasks that the programming language is best at performing.
Below, I'm going to analyze the common and uncommon scenarios and explain which task is better than the other:
1st Common Scenario:
One of the common tasks of any web application would be to access and query the database and output the result to the web server and then to the browser. So on this common scenario, all the programming language is doing is communicating / interfacing with the database server and web server. On this common scenario, the speed of the programming language has almost no affect on this process; the speed of this process relies on the database server, web server, client's web browser / computer and bandwidth.
When it comes to the main and common database servers, MySQL (now owned by Oracle), PostgreSQL, MSSQL and Oracle are all fighting for speed and performance. We keep seeing new features and better performance by all database servers in each version upgrade so I will say that the above database servers will all have a great performance if the database programmers use optimized and practical SQL queries and if needed, use the advanced features such as caching.
MySQL is used by Google, Facebook, YouTube, Yahoo and recently on FIFA World Cup which received a huge audience around the World. So I would not question the capability of the MySQL database server.
Based on my research on a few online stats, as of this writing, the communication and interfacing between PHP and MySQL is faster than ASP.net and MSSQL but it is not very noticeable.
2nd Common Scenario:
One of the other common tasks of any web application would be to access the file system, find an image and send it to the web server. In this case, again, the programming language is doing very little — it is the Operating System and the file system that has the burden of communicating with the programming language.
Based on my research on a few online stats, as of this writing, the Linux OS and ext4 (file system) performs better (IO) than Windows OS and NTFS (file system.)
3rd Common Scenario:
Most Linux / Unix servers are run very lean without any extra un-needed packages or GUI interfaces and therefore the OS uses a lot less CPU and RAM which provides more allocation to the database and web server.
Most windows servers run clunky and with many un-needed packages and GUI which will be using much more CPU and RAM.
Obviously, a LAMP platform will have an advantage over the ASP.net platform because it will have more available resources.
4th Not Very Common Scenario:
ASP.net is usually written in C# (pronounced C Sharp) — generally speaking, as of this writing, C# is a faster programming language than PHP. (This may change as each programming language will come up with upgrades to fight for a better speed.) So if the programming language needs to run a 2,000,000 loop execution of a calculation, an ASP.net written in C# will win over PHP. However, this is a very uncommon scenario, the most loop executions of a calculation would be in 100s and not 2,000,000s. And in this case, there should be other concerns about why someone needs to do a 2,000,000 loop calculation.
Additional items that can have an effect on performance but have nothing to do with which programming language is selected are:
Ability and knowledge of programmer(s) to optimize the code
Ability and knowledge of programmer(s) to write proper and optimized SQL queries.
Functionality required (some functions may take longer to execute in the ASP.net platform and less time in PHP platform and vice versa.
III. Cost:
PHP, MySQL server, PostgreSQL server, Apache server, and Linux OS are all free and upgrades are also free. In addition, there is no additional licensing cost for having another hot standby server as a backup, or needing to run multiple servers for load balancing or server clustering.
LAMP (Linux, Apache, MySQL and PHP) is also much more popular among hosting companies, and its popularity results in a lower monthly hosting cost for LAMP hosting compared to Windows hosting.
ASP.net and IIS are free if you purchase Windows OS. There is a substantial licensing cost for a Microsoft Windows Server, Microsoft SQL Server and future upgrades. For example, Microsoft Server 2008 R2 Standard - 64-bit cost is about $1029 and Microsoft SQL Server 2008 Standard Edition For Small Business cost approximately $1038.
The above licensing costs for Microsoft can substantially increase if the site becomes popular and there is a need to run the site on multiple servers or requires server features such as load balancing, server clustering or hot standby.
V. Time to Deploy
It takes a larger amount (more lines) of code to accomplish complex features and functionality with ASP.net compared to PHP, adding more time to the development process.
Additionally, PHP is interpreted at the server, so when changing a functionality, no additional steps are required to see the changes. On the other hand, ASP.net needs to be compiled each time the code is modified. Again, the development process is more time-consuming when using ASP.net as opposed to PHP.
VI. Platform Independent
PHP is platform independent and can run on any platform — Linux, Unix, Mac OS X, Windows.
ASP.net is built to run only on Windows platform.
Ageed with gintas, but it's not only about development costs. For typical web tasks language performance is not a bottleneck, it's usually database and webserver performance that are. So you should be better concerned about database, OS and http server to consume more "server". :)
As usual, the answer is "it depends".
Many web applications are not constrained by the speed of execution on the web server layer - typically they run database queries or contact some other resource to magic things onto a page. This tends to have a far more noticable impact on performance than the difference between compiled and interpreted code.
Secondly, PHP and ASP.Net both use a lot of libraries, which are compiled; the total amount of code that executes for a given web request is far larger than the application code. This tends to reduce the impact of the difference between compiled versus interpreted code.
Thirdly, I have experience using both platforms; in practice, PHP and ASP.Net sites tend to have roughly comparable performance and scalability characteristics; if anything, PHP sites are slightly faster.
I recently discovered that it is possible to write windows applications in php. Can someone provide a link to an windows (windows 7) application written in php so I can install and run. I am still kind of sceptical that this is possible. Seeing is believing
Edit There are a lot of broken links on the apps page of the phpgtk community site mentioned in a couple of answers. I am looking for an exe that I can download and install to prove to me that it is possible(and practical). A lot of the applications on the phpgtk site are a bit of a joke(tick tac toe, click a button as fast as you can etc), are there any serious desktop applications being written in php or should I just give up on the idea now and pursue c++ for desktop applications?
As far as I know, PHP-GTK is sort of dead, or at least very inactive. Not that it ever had a very active community anyway ...
There are also a few other PHP GUI projects out there, personally I wouldn't use any of them, for the simple reason that IMHO PHP is lacking features to write serious GUI applications, the biggest is probably the lack of threads, or any other serious multi-processing capabilities for that matter...
There is pcntl_fork(), which works (used it a few times), but it has the major the drawback that it doesn't work on Windows. One might also argue that using fork()is inferior to using threads, but that's a different discussion.
Especially with a GUI you'll probably want some sort of threading support, let's say your GUI is doing some operation that'll take 20 second (copy files, download something, etc.), you typically don't want the user interface to freeze while this operation to happen, and you may also want to run multiple operations at the same time.
I'm not sure how PHP-GTK solves these problems, if they solve them at all, but lack of real built-in language support would still cripple you.
There are also other drawbacks to PHP, but those are more general, although you will probably run into them sooner on desktop apps than on web applications (for example, error handling, OS portability, proper UTF-8 support, etc.).
There are many other programming languages which are much better suited for this particular job, and most of them have the advantage of having a (much) larger community than PHP-GTK, which means more docs, more example, more people to ask for help, etc.
C++ might be a good choice, Python, Perl, Ruby, C#, etc, etc. can also be considered. Wikipedia has an extensive list: http://en.wikipedia.org/wiki/Comparison_of_programming_languages
My advice: Choose one that looks Ok and meets your needs, and start hacking. If you don't like it, try something else. ;)
WinBinder is an open source extension for PHP, the script programming language. It allows PHP programmers to easily build native Windows applications.
This should be what you are looking for :)
http://php-gtk.eu/en/apps
there is an awesome extension called WinBinder, I used to work on it. its very easy and straightforward... here is what you can do with it VBM2 sample
also there is PHP-GTK which is a bit hard to learn for people who didn't code Desktop Apps before. however, PHP-GTK is powerful and has better support and you can develop apps on cross-platforms.
We are planning to develop a email marketing system. We are trying to decide if we shall use LAMP stack or MS.NET with SQL server.
I understand MS.NET is faster/easier to develop and has support from MS but in the long run it will cost more considering the licensing cost.
I guess LAMP will cost less and can also be scaled as good as MS.NET and SQL server architecture.
Can you pl provide your valuable feedback considering following criteria:
Overall development and maintainance cost
Scalability of software using PHP/MySQL and MS.NET/Sql Server
Speed of development and availablity of development tools.
...anything criteria you deem important.
Also, what do you think about hybrid approach of MS.NET and MySQL. It will give RAD (rapid application support) of .NET and reduce database licensing cost.
From my experience with web development...
You're probably looking at a slightly higher development and maintainence cost with .Net. Generally, hosting is more expensive for .Net (although there is a free version of MS SQL) as the underlying software is more expensive. Naturally, it depends what you consider expensive / too expensive at this stage in your business - but you can't beat the cost of Linux.
I believe that .Net has the potential for more efficient scalability but it's pretty much a subjective topic, as the scalability will depend on the way that the system is programmed, the quality of the code produced and many other factors. Realistically, this unlikely to be an issue until the system is very large.
Development speed will depend on what your programmers are more comfortable with. .Net has a nice set of built-in controls and some really nice commercial packages to really speed things up (Telerik controls for instance, though they are not cheap!). There are also a number of very mature frameworks for PHP that can drastically reduce development time - I personally like CodeIgniter (free). I believe the determining factor on this point really does depend on your coders and their skills / experience with the languages.
The free version of MS SQL is free up to some very reasonable limits - the sort of limits that, if you hit them, you should be making enough money that upgrading isn't a problem!
At the end of the day, you should discuss what everyone feels most confortable developing with - if you want clean / good code, you're much less likely to get that if you're also learning a new language as you go. You should also decide what your limits are for the other factors to determine if there is enough of a difference that will realistically impact on your product - for instance you could try to compare performance between the two languages forever, but they're both almost certainly fine for your needs - so don't worry too much about it!
I work in both environments. Personally I lean towards PHP. I find that development time is a lot faster because the community (Open Source) is so much bigger. I never have to recreate the wheel. MS has a very cool IDE with a lot of drag and drop functionality but to be honest those controls have limitations and again I'm personally moving more towards a jQuery solution.
Obviously, maintenance and support is a huge issue. This would depend on the project. There are experts out there that you could hire to help if you needed. Some very big sites run on PHP and mySql.
As others have mentioned above, your team might be the final answer to your question. If you only have PHP programmers then I would use PHP. If you have .Net programmers then I would lean towards .Net... If you are hiring out of the box, PHP programmers are usually cheaper (unfortunately).
Just my 2 cents.
There is a free version of SQL server, but of course there is no support for it, so maintenance is entirely on your IT staff, just as it would be with LAMP. Both are equally scalable for most people's needs. PHP has some framework options which can make it just as easy to get an initial system up and running, just as you would with .NET, but no matter which language you choose, the speed of development is all going to be based on your development team.
Its not a fair comparisson if you compared .net with ms sql vs. php with mysql.
Compare using mysql in both, if you are willing to use mysql with php, why not with .net?
That aside, pre-existing skills in the team will make a Huge difference. This applies for both the development aspect and the infrastructure aspect (managing/monitoring the servers).
In my mind, the great advantage of ASP.NET over PHP is the ability to develop code that is shared across web and non-web apps. If you have complicated business logic, that needs to be implemented on your website and on desktop apps or background services, you can put in a .NET assembly and use it any any of them.
The closest platform I can think of that offers similar capabilities is server-side Java. Php simply can't do it.
Of course, you could implement the web UI in PHP, and implement the business logic in web services implemented in .NET or Java...
I've been contacted to see about updating an old legacy web application that was built using ASP and Access. The server is running Windows 2000 Advanced Server and I believe IIS 5.0 (I am trying to get confirmation on that, but the company isn't technical so I highly doubt Apache is running on the server).
What languages would be viable for updating this web app on the above platform? I've never touched classic ASP much less done any web development work against Windows 2000/IIS 5. There are no plans on updating the server to anything new due to budget concerns.
I'm leaning at the moment to moving to an SQLite-based database (customer isn't too keen on installing MySQL at the moment but I'm still in planning stages and this is a relatively low-traffic website) but what language would I pair with that? Does ASP.NET work well under IIS 5? Does PHP perform worth anything under this kind of setup?
I have a similar situation, did it about a year ago, and ended up using asp.net 2.0.
Generally ok, but the machine is showing it's age, I usually need to get someone to give it the 3 fingered salute every month or so, and it blew a psu recently.
If it's only low volume, you might be able to install sql express, which will make your life a lot easier than something like SQLlite, as dotnet plays nicest with other MS stuff, and there is a lot of labour saving goodness built in.
You would also be able to use the access to sql migration tools if you use sql express.
Would also suggest that you look at something like subsonic or nhibernate, which will take care of a lot of the boring and error prone stuff for you.
It really depends on where your experience lies, and how big the project is, if you've never used dotnet before, then start on something small, this may or may not be the one.
Apparently php performs well on win 2008, but as for 2000, never tried. Did have apache on a 2k box many years ago, but wasn't using php.
If the company is concerned with cost, I would be very conservative making changes. Concentrate on why they want to update- do they want to add new functionality? What are their mid-to-long term plans for the site? Are they having trouble maintaining the site? Going to a custom .NET solution may only complicate things further unless they are willing to make some ongoing investment in development.
If it's a relatively simple site, they may want to consider a platform like DotNetNuke. There are hosts out there that sell ready-to-configure sites that can do quite a lot with a minimum of configuration. That combined with a profressionally developed DotNetNuke UI template (TemplateMonster.com offers them) may be a good solution.
If they do want to go with a custom solution, ASP.NET runs fine on IIS 5.0. I believe you can run the .NET Framework up to at least 2.0, not sure about 3.0 or 3.5. Language won't make a difference to functionality, so C# or VB.NET are fine, all things being equal.
In this scenario, I would probably go with ASP.NET. Since you're running on a microsoft server, there will be plenty of documentation from MS on installing, configuring, and running the site. It's a lot easier to support something when all the components are "in the same family" so to speak. Asp.net will run fine under IIS 5. It doesn't have a lot of the security and scalability upgrades that IIS 6 does, but it will do the trick.
I was able to get a bit more information. The box is running IIS 5.0 and the IT guy handling it is more than happy to let me install whatever I need. From googling and responses below it seems like my best bet will be to convert the site to ASP.NET 2.0 with SQL Server Express 2005 running as the DB.
That's something I've been wondering for a while now.
Take Notepad++ for instace. Wikipedia tells me it was written in C++ and it's Windows-only.
Now take PHP. Wikipedia tells me this is also written in C++, but that runs on other OS too.
But I see more languages then just C++ for PHP... how is this done? Do they make some new code in C++, see it works and then figure out how to do it in Perl, or what happens?
It depends whether you are using platform specific libraries or not. Notepad++ is a desktop application and it needs a GUI toolkit. Although there are cross-platform C++ libraries like Qt and wxWidgets, Notepad++ is probably using a Microsoft's specific technology. Thus it can't be ported in other platforms.
PHP on the other side is a WEB scripting technology so there's no need of GUI library. Also there is much more stronger interest in running PHP in many platforms than there is for Notepad++. That is an incentive for the developers to make the C++ code cross platform.
Avoid platform specific libraries isn't the only thing needed for a C++ cross platform application. It usually means coding for the least common denominator and keeping different code branches for every platform supported. Although C++ is a cross platform language, each system has its own intricacies. In fact the code could be different in the same platform as well, if a different compiler was to be used. Try downloading the C++ source of an open source application, like PHP for example. You would notice that much of the code is the same for all platforms, but there would be different bits also. Sometimes preprocessor directives are used, elsewhere totally different source files are involved.
So creating a true cross-platform C++ application is a hard job and it is usually created when there is a strong incentive to do so and many people are involved. An one-man application like Notepad++ really can't be cross-platform.
Usually programs that work on a single platform make use of some facilities from the operating system (e.g. system calls to handle windows, buttons, services). Obviously the code is strictly system-dependent and cannot work in other environments. For cross-platform software you can follow several approaches, some of them are:
You program independently from the operating system and the stuff that lays under your feet (so you don't use operating system facilities, frameworks and so on).
You program using libraries and tools that are programmed that way, and thus work under several operating systems (for instance you use Qt or wxWindows, that are cross-platform, to manage windows and interfaces).
You build several versions of the code, to handle the particularities of the various architectures it will run on. This way you probably achieve more performance and "better" software because the code is optimized for its own architecture, but can be very difficult to maintain.
I think that most languages work in the first way, but sometimes they could use operating system calls to gain some performance (in this case you will have e.g. PHP for Windows, PHP for MacOS, ...).
Unlike some modern languages like Java and C#, C++ the language provides only basic functionality. It has no standard way of handling the user interface, threads, network interaction, cryptography, or even reading XML. Instead, support for this sort of functionality is left up to the operating system. Windows provides a broad API set called Win32 that applications written for Windows take advantage. There are similar APIs built on top of Linux and other operating systems. Whenever authors take advantage of the libraries of a specific operating system, they make it so their programs won't work on other operating systems.
It is possible to write a C++ program that will work across operating systems by abstracting away the items that interact with the operating system, but this is not simple and isn't often done.
C++ is an inherently cross-platform language; it's just that there are lots of libraries written in C++ that use features specific to a particular platform, so those programs are limited to that platform. Avoid those platform-specific features, and you've got yourself a C++ program that should compile on most platforms without too much hassle.
Notepad++ is Windows only because Notepad++ is a replacement for Windows Notepad, which is notoriously bad. No-one on any self-respecting OS would use an editor with 'Notepad' in the name ;>.
The core of Notepad++ is the Scintilla text editor component, which is cross-platform (Linux, OS X and Windows) and is used in both cross-platform and platform-specific applications. The core view logic is shared, with abstract classes for interfacing with windowing systems and graphics contexts. The applications take the cross-platform component and bind it to a OS specific window and graphics context. My favourite editor on Linux and Windows is SciTE, which is a very fast light wrapper around the editor with Lua scripting; there's also Komodo which wraps the Scintilla editor component in a Mozilla XUL container - another cross platform C++ stack.
There is some cost to making applications cross-platform; it's only worth that investment if there are prospective users on those platforms.
Apart from platform-specific libraries and APIs, C and C++ are also not truely cross-platfrom languages (for a good reason). They intentionally leave a lot of details unspecified, like type lengths, endianness, variable alignment in structs and whether newly allocated memory is initialzed.
This allows you to write (platform-specific) code that is as fast as your CPU can possibly go, but it also means that if you want your code to be portable, it takes some additional effort and testing - which many people targeting the Windows/x86 platform probably skip.
Others have commented on GUIs and use of other libraries that exist on only a subset of major platforms.
Another factor is the developers. Many developers (or software companies) only have expertise, access to, customer demand for, or need to use a single platform, and so they don't spend the extra effort to make their software cross-platform. For example, if a company has a Windows PC and developer tools on everybody's desk, no Linux or Mac machines in house to develop or test on, and no developers who are experts on those other platforms, and no large customers demanding a different platform, it's hard for them to justify not just plowing ahead with a Windows-only package. And if they change their mind later, when they have the expertise, equipment, or additional requirements, they may find it's too late to fix a large code base that has been allowed to become very platform-dependent.
Platform-independence takes real effort, every step of the way. If you start from day one with a plan, use cross-platform libraries (e.g., Qt, boost, OpenGL, etc., carefully avoiding MFC, DirectX, etc.), and build and test on all platforms regularly, it's probably only 10-20% more effort to make a good cross-platform app. But if you start with a one-platform app that's been in development for a long time, making it cross-platform can take as much effort as writing it from scratch, and that can be especially hard to justify if the new platform has a comparatively small market share in your industry or if your developers hate working on it.
Now take PHP. Wikipedia tells me this
is also written in C++, but that runs
on other OS too.
PHP is written in C only to make it available on more platforms. There are even rules to only make C style comments, not C++ //.
See PHP coding standards.