Service Fabric

I have been playing a lot with Microsoft Service Fabric. I know that the cool kids are playing with Kubernetes. I was never one of the cool kids, and I don’t think I’ll start now.

Here’s something fun I learned to do.

First, I set up Service Fabric locally on my development machine. Microsoft calls that "OneBox”.

Then I created two services. One is a Reliable Actor service. I haven’t really done anything with that yet.

The other service is where I am doing a module for a financial analysis system I’m writing. It’s just a stateless service.

One of the interesting things about Service Fabric is that you have have your service provide multiple endpoints.

My stateless service has two endpoints. One of those endpoints is a Service Bus queue listener. It listens for messages coming in from one queue, and then responds with messages on another queue. I’m working out a scheme of messages so that it’s easy (ish?) to tell when you’ve received a message that corresponds to a message you sent.

The stateless service also has a Kestrel web service listener. I’m not using ASP.NET Core, because the Service Bus listener hasn’t been ported to .NET Standard or .NET Core, but that’s okay with me. I am totally fine running this thing using .NET Framework because it will always be on Windows.

My idea is this:

The stateless service actually will be controlling some state that is held in a data store. I’m trying to sorta-kinda follow the Command Query Responsibility Segregation principle. I’m expecting that Commands will often take a while to complete, and so they will generally come in the form of Service Bus messages. Queries, however, I hope to respond almost immediately (although I’m definitely doing everything in an async-friendly fashion), so they are doing to be made available through simpler REST APIs.

This is working pretty well, so far.

One of the interesting things about Service Fabric is that it has a Naming Service so that clients of the services in Service Fabric can use a consistent name, and it gets dynamically resolved at run time to an actual endpoint direct to the service, bypassing any middle step. This implies the client must be ready to retry requests if the service fails, but that’s usually pretty simple to do. (I’m hoping that Polly will have something to help with that.)

And, to make it easy to experiment, there are PowerShell cmdlets that help.

Step 1: Connect to the OneBox Service Fabric cluster. This couldn’t be easier:


Step 2: Get the endpoints from the Naming Service. You’ll need the Service Fabric name of the service.

$ussec = Resolve-ServiceFabricService -PartitionKindSingleton -ServiceName fabric:/Server.ServiceFabric/Server.Ledger.UsSec

Step 3: Get the Address from the Endpoint(s):


And that’s pretty much it. The Address is a JSON string, so there’s still some parsing to do.

I’ll work on that tomorrow.

Also, I’d like to see if I can name that second, anonymous endpoint.


Alan McBee

comments powered by Disqus