HTTP is all around us – it has become the de facto transport protocol of choice; web servers may be the primary source, but routers / access points have used it for a long time, databases have begun to use it (e.g. CouchDB, RavenDB), and now even console apps have taken to its user-friendly interface. We’ve been using Mercurial on our latest project, which is a fantastic application in its own right, and despite being essentially a console application, it too contains its own HTTP server. Type in “hg serve” at the command line, and it will start up a single-use dedicated HTTP server, which provides a great online user interface.
I won’t go into the details (you can try it yourself), but it did set me thinking. Running background applications on a server have always suffered from the lack of user interface, but embedding an HTTP server in the application would allow you to offer this**. Moreover, within a locked-down production environment you could provide network access to an application using a protocol that sysadmins understand.
Digging a little deeper, I came across Kayak – a lightweight .NET HTTP server, which would allow just this. It should be possible to use this (or an equivalent) to bundle an HTTP server in with your services to serve up things like: logs, service status (e.g. databases up, network locations running) & configuration information. This would also allow you to manage / update configuration settings in runtime, and to combine multiple services into a simple management console.
Ultimately, it would be great to provide a mechanism for uploading software updates – in the same way that you update router firmware – navigate to a URL, upload an update package, and then restart the service. Add in scripting support, and it would make management of a multi-server environment much, much simpler, without the need for an expensive System Centre type application.
I’m so convinced that this is a good idea that I’m going to set up a project to demonstrate its application, so watch this space.
** NB – when I say “user” interface, I am obviously talking about the tech-team, not end-users. I’m not advocating opening this kind of interface to the internet – this is internal only!