• Hi

    I tend to take this article as relating purely to production server envs only, although, it brings up some interesting chnge control and testing problems when you dont have a "similar" config in TEST/Pre-Prod. Anyhow, my experience has shown that the seperate web/app server and DBMS servers are mandatory for any serious app that requires stability and scalability. Many a time has IIS or COM+ gone wild, and perf tuning, problem resolution, and patching is much easiser to manage, measure and plan for in the future running seperated servers. Another key reason is security, remembering the servers inside and outside of the DMZ, private networks etc, all make hacking a damn site more difficult in the long term and can really "save your bacon".

    Price is always an interesting arguement in the long term, i have had really cpu intensive apps that generally do bugger all work at the db end, and then people start asking questions about how we can utilise all the grunt we have in all the servers. This is a problem for those IT managers that want to cut some dollars here and there and want to host larger numbers of incompatible apps and other 3rd party SW onto a smaller and smaller number of servers and wonder why there are performance problems.

    If you app has definable tiers, is a security/performance concern, differing patch/sw requirements at a variety of levels, always run seperate servers.

    Ive never seen how large scale hosted envs work so I cant comment on any of that 🙂

    Cheers

    Ck


    Chris Kempster
    www.chriskempster.com
    Author of "SQL Server Backup, Recovery & Troubleshooting"
    Author of "SQL Server 2k for the Oracle DBA"