My current situation is that we have four instances of a single windows service running on the server, for production, demo, QA and dev. I am looking for a solution where I just need to run single instance of the service that will hit all the above mentioned databases and process the data.
I know the purpose of having multiple databases (QA, dev etc.) is to do through testing and so I might have to install more than one instances. I am willing to install couple of instances (which is still less than 4 ) so that the maintenance is less.
But is there a way that a single windows service will do some sort of round robin technique and hit one database, do the processing, then hit the another database, do the processing and so on.
Best Answer
If your only goal is to reduce maintenance efforts, I suggest instead of making such a major architectural change to your service, add some tools which allow you to manage the four instances "as one". For example:
starting and stopping of all four instances at once: can be accomplished by start and stop scripts
backing up any data written by your services: just the same, some scripts will do it
producing one log instead of many: make sure your services use standard windows logging mechanics which pipes all logging output of different processes into the standard system or application log
using just one configuration file for all four services instead of four files: put parameters like the DB connection (which must be different for your four use cases) into different sections for QA, dev, test, production inside the configuration file, and separate those from parameters which are the same for all instances. Or, keep using different config files and provide an include mechanism to import config parameters equal for all instances from a shared file.
and if your services need more maintenance tasks, you could even bundle that by creating a special management tool, maybe a command line tool, maybe a tool with a GUI, which makes the maintenance easier.
I guess that will be less effort than merging all the instances into one, and still leaves you in a position with all the benefits you have from four different instances now, like starting and stopping them individually, providing different versions of your program for testing and production, making sure a crash of the testing instance does not affect production, and so on.