Topshelf and JUST EAT
We’re proponents of Event Driven Architecture and for a few components of our system this means we have messages which are pushed into queues and then processed by multi-threaded Windows Service applications. This results in state changes (for example changing the state of an order) followed by further events being published to notify other components of the state change.
Windows Service installation has always been a bit of an arduous task, requiring the creation of installers, usage of installutil.exe for installation configuration and resulting in a difficult to debug application. Topshelf is a great framework for hosting Windows Services and we’ve been using it for a while now. It’s removed the friction around debugging, installation and configuration of our Window Service applications.
Once a Windows Service is installed and running there’s not much interaction to be had with it. It just runs. But sometimes that’s just not good enough. We wanted to know more about the runtime health of our services and be able to use that information to make a decision as to whether the service was healthy. For example:
- are threads completing in a reasonable time?
- do we have good connectivity to external services (SNS, SQS, Dynamo, S3, SQL Server)?
- is working memory usage too high?
In a web application you could have a health check page displaying this information, and this health check page would return a 200 or 500 response so that your load balancers would be able to take them in and out of service. We decided to do the same for our Windows Services and used the Nancy Self Host to host a Nancy endpoint in our Windows Services. We wrapped this up in a Topshelf extension to make it reusable and we used it to expose the health of the Windows Service, so we know when it’s not performing as expected.