Azure Bites: Microservices in Azure

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.

Download the Service Fabric 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.

protected override async Task RunAsync(CancellationToken cancelServicePartitionReplica)
{
    // TODO: Replace the following sample code with your own logic.

    // Gets (or creates) a replicated dictionary called "myDictionary" in this partition.
    var myDictionary = await this.StateManager.GetOrAddAsync<IReliableDictionary<string, long>>("myDictionary");

    // This partition's replica continues processing until the replica is terminated.
    while (!cancelServicePartitionReplica.IsCancellationRequested)
    {

        // Create a transaction to perform operations on data within this partition's replica.
        using (var tx = this.StateManager.CreateTransaction())
        {

            // Try to read a value from the dictionary whose key is "Counter-1".
            var result = await myDictionary.TryGetValueAsync(tx, "Counter-1");

            // Log whether the value existed or not.
            ServiceEventSource.Current.ServiceMessage(this, "Current Counter Value: {0}",
                result.HasValue ? result.Value.ToString() : "Value does not exist.");

            // If the "Counter-1" key doesn't exist, set its value to 0
            // else add 1 to its current value.
            await myDictionary.AddOrUpdateAsync(tx, "Counter-1", 0, (k, v) => ++v);

            // Committing the transaction serializes the changes and writes them to this partition's secondary replicas.
            // If an exception is thrown before calling CommitAsync, the transaction aborts, all changes are 
            // discarded, and nothing is sent to this partition's secondary replicas.
            await tx.CommitAsync();
        }

        // Pause for 1 second before continue processing.
        await Task.Delay(TimeSpan.FromSeconds(1), cancelServicePartitionReplica);
    }
}

So what’s going on here?

The key points are the dictionary and the transaction.

What state?

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).

Transactions

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.

Next Steps

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.