It seems everyone is talking about them. You want to build scalable reliable software where each component can be considered in isolation and called asynchronously. You need Microservices.
Of course there is nothing new about the idea. Break down your big services into small executables that can respond to asynchronous messages. Much like DevOps, Agile and any other buzzword you can think of, Microservices is seemingly a new name for an old idea.
Azure and microservices
Microsoft’s venture into microservices is something called Service Fabric. Service Fabric provides a mechanism to host your microservice based application without requiring you to manage the underlying infrastructure.
The premise is that you focus on building your application, decomposing it into services which you can build separately (and to run asynchronously) and let Service Fabric handle the deployment and reliability for you.
I’m in, where do I start?
Like anything new it’s tough to know where to start with Service Fabric.
Here’s the quickest way I’ve found to get something up and running.
Start with the basics
Start by downloading and installing the SDK.
Once you have that, you’ll need to make a tweak to your Powershell execution policy so that Service Fabric can run the powershell scripts it needs to (for example to deploy your app).
Run powershell as an administrator and execute the following.
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser
Now, when you open up Visual Studio you’ll be able to create a new Service Fabric project in Visual Studio. Create a new application (give it a name) and you’ll be prompted to create a service.
Your application will ultimately be composed of any number of these services and you can mix and match different types.
To get started, choose Stateful under Reliable Services and give your service a name.
You’ll end up with something like this.
One of the projects is your application (HelloWorldSF in this case). This includes publish profiles for local and cloud as well as the Application Manifest which details all the services in your application.
The other one is your service. Somewhere in the service project you’ll find your main service class (in this case Service.cs).
Here’s what it looks like.
So what’s going on here?
The key points are the dictionary and the transaction.
Because of the way Service Fabric deploys your services onto different nodes in your cluster, you can’t rely on the usual C# classes such as Dictionary as their state could reside in multiple instances of the service and incoming requests may be routed between those instances.
Instead, Service Fabric provides it’s own implementations and uses something called StateManager.
StateManager abstracts away all the complications regarding where the state is and gives you the mechanism to Get or Add new instances of Service Fabric’s reliable collections.
In this case we’re getting or adding a reliable dictionary called “myDictionary” which will consist of strings (as the keys) and longs (as the values).
When you call a service asynchronously it’s important that the service either completes it’s job or does nothing.
Here we’re attempting to retrieve the entry from our dictionary with the key “Counter-1”.
If we have the value we broadcast out a service message stating what the current value is. Otherwise we indicate that the value wasn’t found.
Then we add or update the “Counter-1” entry. We create the entry if it doesn’t exist, then increment the value.
Finally the transaction is committed.
It’s only at this point that the state will be updated and all running instances of our service will be updated.
Finally, we pause for a second before continuing (and because we’re in a loop, we’ll go back around and increment the counter again).
Let’s see this thing running then
Hit F5 and visual studio will start to build up your local cluster.
This may take a short while as the cluster is built and services are deployed. Once it’s up and running the Diagnostic Events window will appear.
And there you have it, your service is running asynchronously and sending out messages each time the counter is incremented.
From here we can investigate the different service types and play around with the different reliable collections. In a subsequent post we’ll take a look at adding a web front end to the application.