Cook Computing

Shared Services

September 10, 2005 Written by Charles Cook

Larry Osterman has a post on the advantage of shared services on Windows, arguing that compared to Unix a Windows process is a relatively expensive entity and so it is inefficient if an application splits itself into more than one service each running in its own process.

Each process running drains the system of resources that could be used for your application, so it's important to reduce the number of system processes running. It always annoys me when I install some application and discover that it's installed three or four processes that run all the time on my machine, especially when those functions could have been combined into a single process.

My experience of working on a product running in a single service was that this was a nightmare from a maintenance point of view. Memory leaks and memory corruption can be depressingly difficult to diagnose when you have in the order of hundreds of thousands of lines of C++ code running in the same process. Things are made worse because development was split across several teams and so there was sometimes an unwillingness to fix problems. There was usually no sense of ownership until a problem could be proven to be in a particular product area. The leaks and corruption would get fixed eventually but only after a lot of effort that would have been better directed towards something more productive.

You could argue that more defensive coding techniques and more rigorous development processes should have been in place but it would have been difficult, although worth the investment in my opinion, to introduce these to a product containing a large amount of legacy code. Another recurrent problem was the use of third party libraries. Most of these contained bugs which compromised the reliablity of the system as a whole and with hindsight several of these should have been isolated in their own processes.

I think it was this experience that biased me so much against C++. I don't think it is impossible to develop highly reliable software in C++, its just that the cost of doing so successfully is much higher than most people think and also requires a higher caliber of C++ developer than most teams will be able to recruit. My recruiting experience of the last year or so is that very few developers want to do C++ development now. All interviewees for C++ development positions have indicated some concern about how long it would be before they would move to .NET development (.NET because we don't do use Java). For companies that stick with C++ this is going to be a major problem over the next few years.