Running EventStore as a Windows Service

I’ve been experimenting with EventStore lately. So far it appears to be a great product. The documentation is both good and bad. There is very, very little documentation, yet everything seems to be there. You just need to know where to dig, or watch/read some of the internals videos/blog posts.

The product ships as a simple command line application. That’s great, because it gives you all the flexibility you want. But you probably want to run it in the background as a service anyway so let’s do that.

I set up my machine to support multiple versions without having to change my service definition with every product upgrade. So I created the following drive structure

  ├─latest (--> ./4.0.3-hf1)

where latest is an NTFS junction point to the directory containing the binaries for the latest version. When a new version is released, I can just change to junction point to the newest version.

Next step is to create a Windows Service but EventStore.ClusterNode.exe cannot run as a service directly so you need to wrap it inside a service wrapper like NSSM or winsw. I chose the latter simply because it looked to be the most foolproof to me. I downloaded the WinSW.NET4.exe binary from the releases tab, copied it to C:\EventStore and then renamed it to EventStore.ServiceWrapper.exe. To finish the configuration of the service wrapper, all I needed is an xml file with the service definition in it. Here’s mine.

  <arguments>--db=%BASE%\data --log=%BASE%\logs --run-projections=all --start-standard-projections=true</arguments>

Finally, we need to install/register the Windows Service by calling

C:\EventStore> EventStore.ServiceWrapper.exe install

in a shell with administrative privileges (Windows button + X > Command Prompt (Admin)). Using that shell, you can also start the service

C:\EventStore> net start EventStore

Easy, right?

Best practices

I while ago, somebody came to me and asked whether there is a list of best practices documented somewhere. But do best practices really exist?

Like many things, the biggest problem with “Best practices” is probably its name. The name implies that a given practice works best in all circumstances: always and everywhere. The most important aspect involved in a trade-off seems to be ignored: context.

I (and others) suggest that we get rid of the term “best practice” and rephrase every so-called “best practice” as a pattern instead. Patterns, like the design patterns, consist of four essential elements:

  1. A name: Naming things is important. Given that everybody shares the same understanding of a certain concept, it can help greatly in discussions or conveying intent.
  2. A problem: What are you trying to solve, and in which context?
  3. A solution: How can you solve the problem at hand? Important here is that the solution is generic. It does not dictate every single thing you need to adhere to but, within certain boundaries, leaves room to fine-tune the solution to your needs.
  4. Consequences: Every trade-off has consequences. Whether these consequences are acceptable, depends on your context.

Making the context and consequences for certain patterns explicit will probably also reduce the risk that the pattern will be considered as a silver bullet.