What would be your view on use of technology while building a large portal ?

Lot of large sites today are still on Php. Also, some of them strongly believe J2EE or Dot Net dont deliver the required performance. What would be your view on use of technology while building a large portal ?

You share based on :
1. Ease of development and maintenance
2. Scalabilty
3. Uptime (very critical)

My view are as follows

Sometime back I had a chance to listen to a seminar on Search Engine Optimization (SEO). That seminar pretty much answered why many of the sites still use old technologies. The reason being site indexing in the search engines. Most of these sites are online stores and most of the times customers don't visit their site directly but through a search engine e.g. They query "Digital Camera" and click on one of the results. Now changing the technology would mean re-indexing the site which would definitely take some time (Unless probably if they are ready to pay good amount to search engines). So they run on older technologies to be on the safer side.

For a large portal I would like to put my views on individual factors
1. Ease of development and maintenance
Availability of human resource and tools plays a very important role in success of an application. When we decide upon a particular technology, we must consider what development tools are provide. E.g. IBM Provides Rational Application Developer (May not be free) which allows graphical development of an application, Microsoft provides Visual Studio. But at the same time one must consider the availability of Human resource to use these tools to develop the applications. It should not happen, that a vendor provides an excellent tool which, builds the whole application in no time but, very few people in the market know it how to use it "effectively". As described by Mr. Werner Vogels, CTO, Amazon, developers are artists. They can create a masterpice if give freedom. But they need tools to do it.

2. Ease of maintenance
Ease of maintenance mostly depends on a good design and well followed quality processes. My opinion is one should spend more time in designing than actually implementing it. I have experience with both good and bad designs. I have faced nightmares because of bad designs and lack of documentation. A good design also enables an application to be scalable. If you know that the application is going to grow huge in the future, designers can design it in such a way that future changes involve low cost of development. I feel ease of maintenance does not depend much on the technology because almost every vendor have their own tools to ease the pain of a developer.

3. Scalability
This is a major factor to decide upon the tehnology. Choosing a technology like PHP-MySQL or ASP-SQL Server don't do any good for large system. As described by Mr. Werner Vogels, CTO, Amazon. These technolgies saturate in terms of scalalbility after some time . At that point we need to again re-engineer whole stuff to build the new bigger complex application. Choice of a distributed application makes it easier to scale the application. The current trend is towards building SOA based applications which means every application/module is developed independently as a service and then wired together to form a giant application or portal. This allows parallel development which means reduced development effort and cost and time. But has one drawback. Integrating these components can become painful due of bad developement or design. This could lead an application into trouble. But this can be overcome by a good design and quality processes. Thus for a scalable application one should choose a ditributed application architecure with a good and reputed vendor such as Microsoft, IBM, BEA, Oracle.

4. Uptime
The uptime of the application greatly depends on the stability of the servers and stability of environments. If the infrastructure is not stable we may face problem like connection failures. Though most of the application servers have facility to "retry", number of attempts are limited. If these exceed, you may fall in trouble because you not only have to restart the systems but also verify that transactions are not lost / duplicated due to this restart. This would be real pain. Plus, the downtime because of server reboots can cause a damage to the business.
I have also seen cases where application ran into problem because of the application server itself, it could be a bug in the application server or an unimplemented feature. This could lead you into trouble till you get a fixpack from vendor and get everything online again or it may happen that you require a code change to get it working on top of a fix-pack which again involves a cost.
It also, to an extent, depends on application code. A poorly written application can not only cause application to malfunction but it can also take the server down. Simple example would be closeing DB connections. If an application just keeps on opening connections to database without ever closing them, DB server will deny further connections to the server after the threshold is reached. This would lead servers to go down would need a server restart which leads to significant downtime.

I hope whatever I have written is not complex to understand. If you any further question please feel free to contact me at prasad dot edlabadkar at gmail dot com.