Introduction to Service Fabric

Service Fabric is a new offering from Microsoft to provide a PaaS solution to support microservice architectures. Microservices are a fairly recent trend in service architecture that has been gaining ground very rapidly lately because it offers solutions for scalability, maintenance, and manageability. However, microservices without proper management can easily cause more problems than they solve. Service Fabric has several pieces of functionality that provide a robust platform for deploying and managing microservices which allow organizations to focus on building the microservices rather than scaling, deploying and maintaining them. In this blog post, I'll provide an overview of this platform and key features that show why I believe Service Fabric should be considered in most cloud based implementations of microservices.

Service Fabric can be installed almost anywhere. Out of the box Service Fabric can be deployed in your local Windows development environment simply from Visual Studio. The SDK provided for Service Fabric allows you to run a cluster locally that is identical to what you would run in Azure or on premise. In addition, Service Fabric is available in Azure and can be installed on a Windows or Linux cloud environment that you choose. Due to Service Fabric's portability you can write an application once and then deploy it anywhere without having to worry about environment specific setups or settings.

Local Service Fabric

Service Fabric Dashboard running in a development environment


Deployment

Service Fabric allows you to build and deploy directly from Visual Studio to your local environment, Azure or another place you have installed Service Fabric. You can avoid downtime during upgrades as well as setup policies for automatic repairs. Service Fabric rolls out updates to your application across update domains one at a time. This allows you to keep your application available even during potentially breaking upgrades. Service Fabric also provides a feature to enable auto-rollback of breaking upgrades before the upgrade completes. For example, if your application reported an unhealthy state after deploying to one of the upgrade domains Service Fabric would auto-rollback the deployment. Another useful feature is the ability to deploy multiple versions of your application side by side and even upgrade them independently. Finally, Service Fabric also integrates nicely with Visual Studio Team Services to allow for easy Continuous Integration setup.

Service Fabric Upgrade

Service Fabric upgrading an application


Service Fabric Rollback

Service Fabric automatically rolling back a failed upgrade


Type of Applications

Service Fabric provides both stateful and stateless services. Stateless services are straightforward in that they do not maintain state alongside the code but rather perform some operation that does not require data or accesses an external data store. Stateful services on the other hand require data alongside the code. Service Fabric handles this data by actually placing the data alongside the service in Reliable Collections. Reliable Collections are replicated to provide high availability and to prevent a loss of state in the case of a node failing. Reliable collections also utilize transactions to ensure consistency of the data. A transaction isn't considered complete until it has been applied to a certain number of replicas. All transactions are written to the primary replica for the service and replicated to the secondary replicas. Should the primary replica fail then one of the secondary replicas becomes the new primary. Service Fabric has also solved for deadlocks with Reliable Collections by making use of locking and timeouts.

Below is an example of updating a value in a reliable collection. Notice that the interaction with the collection is considered a transaction and must be committed. If an exception happens before CommitAsync is called then the transaction aborts and the data isn't to any of the replicas.

using (var tx = this.StateManager.CreateTransaction())

{

var result = await myDictionary.TryGetValueAsync(tx, "Counter");

await myDictionary.AddOrUpdateAsync(tx, "Counter", 0, (key, value) => ++value);

// If an exception is thrown before calling CommitAsync, the transaction aborts, all changes are

// discarded, and nothing is saved to the secondary replicas.

await tx.CommitAsync();

}

Service Fabric allows for services to be highly available and scalable in several ways. With stateful services it replicates them across multiple nodes to ensure data availability and reliability. In addition, the application exist on multiple nodes and thus is still available should a node or even multiple nodes fail. The same is true for stateless services, which can also be deployed to multiple nodes to remain highly available. A key difference between the stateful and stateless services also concerns scaling. To scale stateless services you simply would increase the instance count. However, scaling stateful services is a bit trickier because of the data sitting alongside the application. Service Fabric provides partitions that allow you to distribute the application across multiple nodes. Partitions break stateful services into multiple primary nodes that handle a different section of the overall service's data and where each has its own set of secondary replicas. For example, if your stateful service was storing counts for each letter of the alphabet then partition one would handle A-E, two would handle F-J, three would handle K-O, four would handle P-T, and five would handle U-Z. This is done by routing calls to the different partitions via logic in the application that is communicating with the stateful services.

Monitoring

A key component of Service Fabric is the ability to report both health and resource utilization. The ability to report health in a service fabric cluster allows for you to better triage, diagnose and prevent issues with your application. Service Fabric provides a hierarchical health reporting structure that allows you to report the health of the cluster, individual nodes, the application, a particular service, a partition or a replica. Monitoring resource consumption load allows for the cluster to better balance your application and services across nodes. For example, being able to dynamically report CPU or memory would allow the cluster to adjust service distribution to avoid under or overutilization of your cluster.

Below is an example of sending an error health check message to Service Fabric. Some desired state or condition has arisen that causes us to consider the partition to be in an unhealthy state. We simply create a HealthInformation object, configure some values to remove and expire the state after a certain amount of time and then report it.

if (!result.HasValue)

{

var healthInformation = new HealthInformation("ServiceCode", "StateDictionary", HealthState.Error);

healthInformation.RemoveWhenExpired = true;

healthInformation.TimeToLive = TimeSpan.FromMinutes(5);

this.Partition.ReportReplicaHealth(healthInformation);

}

Conclusion

Service Fabric offers many out of the box features that provide a highly available, configurable, and scalable environment to deploy microservices to. In addition to all of these features, the ability to run Service Fabric almost anywhere provides anyone with the ability to integrate it into their existing infrastructure. Managing the infrastructure for microservices via a PaaS solution like Service Fabric enables developers to construct a solution with minimal effort and future maintenance. Given the aforementioned robust features Service Fabric provides it is an obvious choice for maintaining microservices in the cloud.

About the Author

Casey SilverCasey Silver is a Software Engineer in CapTech's Systems Integration practice, where he specializes in developing .Net and cloud based applications.