Stateless services on Azure Service Fabric in F#

In my previous posts, I discussed the use of the Service Fabric (SF) actor framework (which is loosely based on Orleans) and F#, and how we can use FP features within an actor model, even one designed for OO languages.

Exposing Services with Service Fabric

Ironically, the actor framework with SF is one of its more complex features – you can use SF to host literally any .NET code you want. There are a number of features within SF designed to allows you to rapidly host scalable systems, with support for state replication out-of-the-box. In this post, I want to illustrate the steps needed to host the F#, FP-first web server Suave in Service Fabric. It turns out that there’s really not much code needed at all.

1. We create an F# executable that is compatible with Service Fabric.
2. We create a service that inherits from the StatelessService class (we’ll discuss Stateful Services in another post).
3. We override the CreateCommunicationListener method. This is important – essentially this method’s responsibility is to create an object that can handle incoming traffic from external sources. We also make a note of the port that Suave will be running on.
4. We configure an endpoint in the Service Fabric configuration for that same port. This tells SF to allow inbound traffic in. This is roughly analogous to opening up an endpoint in Cloud Services. This is something you should have also specified when creating the cluster itself in Azure (if not, you’ll need to manually configure the load balancer to allow traffic through).
5. In our Main program, we register the service with SF.

The key part is (3), where we implement the functionality that should get called to handle incoming requests. It’s pretty basic really: –

	open Microsoft.ServiceFabric.Services
	open Suave
	open Suave.Http.Successful
	open Suave.Web
	open System.Fabric
	open System.Threading
	open System.Threading.Tasks
	type SuaveService() =
	inherit StatelessService()
	override __.CreateCommunicationListener() =
	{ new ICommunicationListener with
	member __.Abort() = ()
	member __.CloseAsync _ = Task.FromResult() :> Task // should close down gracefully
	member __.Initialize _ = () // any initialization goes here
	member __.OpenAsync cancellationToken =
	async {
	let starting, server = startWebServerAsync defaultConfig (OK "Hello from Service Fabric!")
	Async.Start(server, cancellationToken)
	do! starting |> Async.Ignore
	return (defaultConfig.bindings.Head.ToString())
	} |> Async.StartAsTask
	}

view raw

suave-on-service-fabric.fs

hosted with ❤ by GitHub

So CreateCommunicationListener() expects an instance of ICommunicationListener that will create the web server for us. Luckily with F#’s object initializers we don’t even have to declare a formal type – we can simply create the object on the fly. As you can see, all it does is start up Suave using default settings. You might elect to supply the port that it starts on from the endpoint configuration in Service Fabric – this is done in the Initialize method, and is included in the full sample.

Once done, you can configure the scalability of the service in config – if you want three instances, just set the instance attribute to 3 in the ApplicationManifest file of your hosting Service Fabric application. If you want it on every node, you set the attribute to -1 (because we all know that -1 is the universal standard for “absence of a number” – we don’t need no option types ;-). Note that running this locally with multiple instances won’t work, since they all try to run on the same port, but in the real world it’d work fine I’m sure.

As an aside, if you want any arbitrary service that doesn’t necessarily need incoming traffic e.g. something subscribing to service bus or writing to a DB, you don’t have to implement anything regarding ICommunicationListener. There’s simply a RunAsync() method that you can put any code inside that you want.

So, there you have Suave in Service Fabric with a minimal amount of code. For this you’ll get an auto-load balancing, scalable and automatically healing service. In my next post, I’ll demonstrate StatefulServices and how we can use them to automatically manage state across a cluster of services.