• Article

December 2015

Volume 30 Number 13

Microsoft Azure - Azure Service Fabric and the Microservices Architecture

By Cesar de la Torre, Kunal Deep Singh,, Vaclav Turecek | December 2015

Microservices is a hot buzzword at the moment. While there are many presentations and conference talks about the subject, a lot of developers remain confused. A common question we’ve heard: “Isn’t this just another service-oriented architecture (SOA) or domain-driven design (DDD) approach?”

Certainly, many of the techniques used in the microservices approach derive from the experiences of developers in SOA and DDD. You can think of microservices as “SOA done right,” with principles and patterns like autonomous services, Bounded-Context pattern and event-driven all having their roots in SOA and DDD.

In this article we address both microservices theory and implementation. We’ll start with a short introduction to microservices, and then move on to the practical side and how you can build and deploy microservices with Azure Service Fabric. Finally, we’ll show why this platform is a great fit when building microservices.

As the name implies, microservices architecture is an approach to build a server application as a set of small services, each service running in its own process and communicating with each other via protocols such as HTTP and WebSockets. Each microservice implements specific, end-to-end domain and business capabilities within a certain Bounded-Context per service, and must be developed autonomously and deployed independently by automated mechanisms. Finally, each service should own its related domain data model and domain logic, and can employ different data storage technologies (SQL, No-SQL) and different programming languages per microservice.

Examples of microservices include protocol gateways, user profiles, shopping carts, inventory processing, purchase subsystem, payment processing, and queues and caches.

Why microservices? In a word, agility. Over the long term, microservices enable superior maintainability in large, complex and highly scalable systems by designing applications based on many independently deployable services that allow for granular release planning.

As an additional benefit, microservices can scale out independently. Instead of having giant monolithic application blocks that you must scale out at once, you can instead scale out specific microservices. That way, just the functional area that needs more processing power or network bandwidth to support demand can be scaled, rather than scaling out other areas of the application that really don’t need it.

Architecting fine-grained microservice applications enables continuous integration and continuous development practices, and accelerates delivery of new functions into the application. Fine-grain decomposition of applications also lets you run and test microservices in isolation, and to evolve microservices independently while maintaining rigorous contracts among them. As long as you don’t break the contracts or interfaces, you can change any microservice implementation under the hood and add new functionality without breaking the other microservices that depend on it.

As Figure 1 shows, with the microservices approach it’s all about efficiency for agile changes and rapid iteration, because you’re able to change specific, small portions of large, complex and scalable applications.

Microservices Approach Compared to Traditional Server Application Approach
Figure 1 Microservices Approach Compared to Traditional Server Application Approach

Data Sovereignty Per Microservice

An important rule in this approach is that each microservice must own its domain data and logic under an autonomous lifecycle, with independent deployment per microservice. This is really no different from how a full application owns its logic and data.

This approach means that the conceptual model of the domain will differ between sub-systems or microservices. Consider enterprise applications, where customer relationship management (CRM) applications, transactional purchase subsystems and customer support subsystems each call on unique customer entity attributes and data and employ a different Bounded-Context.

This principle is similar in DDD where each Bounded-Context, which is a pattern comparable to a subsystem/service, must own its domain-­model (data and logic). Each DDD Bounded-­Context would correlate to a different microservice.

On the other hand, the traditional (or monolithic) approach used in many applications is to have a single and centralized database (often a normalized SQL database) for the whole application and all its internal subsystems, as shown in Figure 2. This approach looks initially simpler and seems to enable re-use of entities in different subsystems to make everything consistent. But the reality is you end up with huge tables that serve many different subsystems and include attributes and columns that simply aren’t needed in most cases. It’s like trying to use the same physical map for hiking a short trail, taking a day-long car trip and learning geography.

Data Sovereignty Comparison: Microservices vs. Monolithic
Figure 2 Data Sovereignty Comparison: Microservices vs. Monolithic

Stateless or Stateful Microservices?

As mentioned earlier, each microservice must own its domain model. In the case of stateless microservices, the databases will be external, employing relational options like SQL Server or NoSQL options like MongoDB or Azure Document DB. Going further, the services themselves can be stateful, which means the data resides within the same microservice. This data can exist not just within the same server, but within the same microservice’s process, in-memory and persisted on hard drive and replicated to other nodes.

Stateless is a perfectly valid approach and easier to implement than stateful microservices, as it is similar to traditional and well-known patterns. But stateless microservices impose latency between the process and data sources, while also presenting more moving pieces when improving performance via additional cache and queues. The result: you can end up with complex architectures with too many tiers.

Stateful microservices, on the other hand, can excel in advanced scenarios, as there is no latency between the domain logic and data. Heavy data processing, gaming back ends, databases as a service, and other low-latency scenarios all benefit from stateful services, which enable local state for faster access.

The drawback: Stateful services impose a level of complexity in order to scale out. Functionality that would usually be implemented within the external database boundaries must be addressed for things such as data replication across stateful micro­services replicas, data partitioning and so on. But this is precisely one of the areas where Service Fabric can help most—by simplifying the development and lifecycle of stateful microservices.

Benefits of Azure Service Fabric

All the goodness that comes with the microservices approach comes with a drawback. Distributed computing and complex microservices deployments can be hard to manage if you do it by yourself. Service Fabric provides the plumbing needed to create, deploy, run, and manage microservices in an effective and efficient way.

What is Service Fabric? It’s a distributed systems platform used to build hyper-scalable, reliable and easily managed applications for the cloud. Service Fabric addresses the significant challenges in developing and managing cloud applications. By using Service Fabric, developers and administrators can avoid having to solve complex infrastructure problems and focus instead on implementing mission-critical, demanding workloads knowing that they’re scalable, reliable and manageable. Service Fabric represents Microsoft’s next-generation middleware platform for building and managing these enterprise class, Tier-1 cloud scale services.

Service Fabric is a universal deployment environment; you’re able to deploy any executable based on any language (Microsoft .NET Framework, Node.js, Java, C++) or even database runtimes like MongoDB.

Therefore, it’s important to make clear that Azure Service Fabric is not limited to microservices-oriented applications. You can also use it to host and deploy traditional applications (Web apps or services) and get many benefits related to scalability, load balancing and fast deployment. Yet Azure Service Fabric is a new platform built from the ground up and especially designed for hyperscale and microservices-based systems, as shown in Figure 3.

Microsoft Azure Service Fabric
Figure 3 Microsoft Azure Service Fabric

Here are some of the benefits of Service Fabric:

  • Runs on Azure, on-premises or in any cloud. A very important characteristic of Service Fabric is that you can run it on Azure, but also on-premises, on your own bare-metal servers or virtual machine (VMs), and even in other third-party hosted clouds. There’s no lock-in to a specific cloud. You could even run a Service Fabric cluster in Amazon Web Services (AWS).
  • Supports Windows or Linux. Currently (late 2015) Service Fabric supports Windows, but it will also support Linux and containers (Windows images and Docker images).
  • Fully vetted. Service Fabric has been used for several years by Microsoft to power many of its cloud products.

Service Fabric was born out of the need to build large-scale services within Microsoft. Taking products such as SQL Server and building them as services available in the cloud (Azure SQL Database) while being agile, reliable, scalable and cost-effective required a distributed technology that could meet all of these demands effectively. While the core technology that solved these complex scenarios was being built, it became apparent that SQL Server was not the only product that was making such a leap. Products such as Skype for Business had to solve similar problems on the path to becoming a microservices-based application. Service Fabric is the application platform that evolved out of these challenges and has been used in many large-scale services at Microsoft with varying architectures and requirements for running at scale. InTune, DocumentDB and the back end for Cortana and Skype for Business all are services that run on Service Fabric.

The experience supporting mission-critical systems has enabled Microsoft to design a platform that intrinsically understands the available infrastructure resources and needs of scalable applications. It enables the automatically updating, self-healing behavior that is essential to delivering highly available and durable services at hyper scale. Microsoft now makes this battle-hardened technology available for everyone.

Azure Service Fabric Programming Models

Service Fabric offers two high-level frameworks for building services: the Reliable Services APIs and the Reliable Actors APIs. While both are built on the same Service Fabric core, they make different tradeoffs between simplicity and flexibility in terms of concurrency, partitioning and communication, as shown in Figure 4. It’s useful to understand how both models work so that you can choose the framework better suited for your service. In many application scenarios, you can have a hybrid approach and use actors for certain microservices and employ reliable services to aggregate data generated by a number of actors. Therefore, a reliable service could orchestrate actor services in many common scenarios.

Figure 4 Comparing Service Fabric Programming Models

Reliable Actor APIs Reliable Services APIs
Your scenario involves many small independent units/objects of state and logic (live Internet of Things objects or gaming back-end scenarios are great examples) You need to maintain logic and queries across multiple entity types and components
You work with a massive amount of single-threaded objects while still being able to scale and maintain consistency You use reliable collections (like .NET reliable Dictionary and Queue) to store and manage your state/entities
You want the framework to manage the concurrency and granularity of state You want to control the granularity and concurrency of your state
You want Service Fabric to manage the communication implementation for you You want to decide on, manage and implement the communication protocols (Web API, WebSockets, Windows Communication Foundation and so on)
You want Service Fabric to manage the partitioning schema of stateful actor services so it’s transparent for you You want to control the partitioning scheme of your stateful service

Building Stateless Microservices with Azure Service Fabric

A microservice in Azure Service Fabric can be almost any process in the server you want to create, whether it’s the .NET Framework, Node.js, Java or C++. Currently only the .NET and C++ libraries of the Service Fabric API are available. Therefore, you need to implement microservices in the .NET Framework or in C++ for low-level implementations.

As mentioned, a stateless micro­service is one where there’s a process (such as a front-end service or business-logic service), but there’s literally no state persisted within the service, or the state that’s present is lost when the process ends and doesn’t require synchronization, replication, persistence or high availability. It could have a related external state, but persisted in external storage such as Azure SQL Database, Azure Storage, Azure DocumentDB or any other third-party storage engine (relational or NoSQL). Therefore, any existing service such as ASP.NET Web API service running on Cloud Services, Worker Role or Azure Web App would easily migrate to Service Fabric stateless services.

To set up your development environment, you need to have the Service Fabric SDK, which lets you run a local development cluster that’s not an emulator, but runs the same bits as in Azure. Additionally, Visual Studio 2015 tooling integration makes development and debugging easier.

Before deploying and debugging services in your local machine, you need to create the cluster of nodes. You do that by running the Windows PowerShell script called DevClusterSetup.ps1, as explained in the “Install and Start a Local Cluster” section of the documentation page, “Prepare Your Development Environment,” located at bit.ly/1Mfi0LB. You can refer to this page for a complete walk-through of the set up process. 

Stateless Service Base Class Any stateless Service Fabric service class has to derive from the Microsoft.ServiceFabric.Services.StatelessService class. This class provides API methods and context related to the Service Fabric cluster and the execution environment, and hooks into your service’s lifecycle.

Whether your service is stateful or stateless, Reliable Services provides a simple lifecycle that lets you quickly plug your code in and get started. There’s really just one or two methods that you need to implement to get your Service Fabric service up and running—typically RunAsync and CreateServiceReplicaListeners—which we’ll explain when drilling down on the communication protocols.

Note RunAsync as shown in Figure 5. This is where your service can “do work” in the background. The cancellation token that’s provided is a signal for when that work should stop.

Figure 5 Base Structure of Stateless Service in Azure Service Fabric

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {   
      int iterations = 0;
      while (!cancellationToken.IsCancellationRequested)
      {
        ServiceEventSource.Current.ServiceMessage(this, "Working-{0}",
          iterations++);
        // Place to write your own background logic.
        // Example: Logic doing any polling task.
        // Logic here would be similar to what you usually implement in
        // Azure Worker Roles, Azure WebJobs or a traditional Windows Service.
         await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
      }
      } 
    }
}

Communication Protocols in Azure Service Fabric Reliable Services Azure Service Fabric Reliable Services provides a pluggable communication model. You can use the transport of your choice, such as HTTP with ASP.NET Web API, WebSockets, Windows Communication Foundation, custom TCP protocols and so on.

You can implement your own code for your chosen communication protocol in your service or use any communication stack provided with Service Fabric, such as ServiceCommunicationListener/ServiceProxy, which is the default communication stack provided by the Reliable Services Framework in Service Fabric. There will also be separate NuGet packages with additional communication stacks that you can plug into Service Fabric.

Using ASP.NET Web API in Service Fabric Microservices As mentioned before, Service Fabric lets you decide how you want your services to communicate, but one of the most common ways to create HTTP services in the .NET Framework is by using ASP.NET Web API.

Web API in Service Fabric is the same ASP.NET Web API you know and love. You use controllers, HttpRoutes and you can build REST services the same way by using the MapHttpRoute or attributes on the methods you want to map to Http routes. The difference when using Service Fabric is how you host a Web API application. First to take into account is that you cannot use IIS in Azure Service Fabric, as it uses just plain processes replicated across the cluster, so you have to self-host the HTTP listener in your code. In order to do that for Web API services, you have two choices:

  • Use ASP.NET 5 Web API (code name “Project K”) to self-host the HTTP listener within your Service Fabric microservices process.
  • Use OWIN/Katana and ASP.NET 4.x Web API to self-host the HTTP listener within your Service Fabric microservices process.

Running ASP.NET 5 on top of Azure Service Fabric is the best fit for building microservices because, as mentioned earlier, Service Fabric lets you deploy any number of services into each node/VM, allowing high microservices density per cluster. Additionally, that high density will get even better when Service Fabric eventually delivers .NET Core 5 and CoreCLR support in the future (underneath ASP.NET 5). It’ll be “best of choice” to achieve super-high density of microservices because .NET Core 5 is a light framework with a very small memory footprint compared to the full .NET 4.x Framework.

Using “MVC-Type” Web Apps and Service Fabric Microservices ASP.NET MVC is a very popular framework for traditional Web sites, but you cannot use the “old” MVC framework (MVC 5 or older) with Service Fabric. This is due to the fact that in Service Fabric you need to self-host the HTTP listener in your process and that OWIN/Katana is not supported in ASP.NET 4.x MVC (It’s supported only in ASP.NET 4.x Web API.) Therefore, the options you have to implement an “MVC-type” Web application on Service Fabric services are the following:

  • Use MVC 6 in ASP.NET 5 to self-host the HTTP listener within your Service Fabric microservices process. It supports MVC because in ASP.NET 5, Web API and MVC are consolidated and are in fact the same framework with the same controllers with no dependency to IIS. This will be the preferred choice as soon as ASP.NET 5 is released to manufacture.
  • Use ASP.NET 4.x Web API with OWIN/Katana to self-host the HTTP listener within your Service Fabric microservices process and simulate MVC controllers with Web API controllers and use HTML/JavaScript output rather than regular Web API content (JSON/XML). The documentation page at bit.ly/1UMdKIf demonstrates how to implement this technique.

Implement Self-Hosting with ASP.NET 4.x Web API and OWIN/Katana

For this approach, the Web API application you’re used to working with doesn’t change. It’s no different from Web API applications you may have written in the past, and you should be able to simply move most of your application code right over. Hosting the application may be a little different from what you’re used to if you’ve been hosting on IIS.

CreateServiceReplicaListeners Method in Service Class This is where the service defines the communication stacks it wants to use. The communication stack, such as Web API, is what defines the listening endpoints for the service, as well as how those messages that show up will interact with the rest of the service code.

Going back to the service class mentioned before in Figure 4, I now just have to add a new method called CreateServiceReplica­Listeners, which specifies at least one communication stack I want to use. In this case, it’s the OwinCommunicationListener used by Web API, as shown in Figure 6.

Figure 6 Adding the CreateServiceReplicaListeners Method to the Stateless Service Class

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation.
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {            
      // Place to write your own background logic here.
      // ...         
    }
    protected override IEnumerable<ServiceReplicaListener>
      CreateServiceReplicaListeners()
      {
        return new List<ServiceReplicaListener>()
        {
          new ServiceReplicaListener(parameters =>
            new OwinCommunicationListener(
            "api", new Startup()))
        };
      } 
    }
}

It’s important to highlight that you can have multiple communication listeners added to your service.

The OwinCommunicationListener class is boilerplate code that you’d reuse across all your microservices. In a similar way, you could be plugging in other protocols (WCF, WebSockets and so on).

If you’re creating a Web API microservice, you still will have controllers with typical code no different to what you might be used to when implementing Web API services, like the following code:

// Typical Web API Service class implementation
public class CustomerController : ApiController
{ 
  //// Example - GET /customers/MSFT
  [HttpGet]
  [Route("customers/{customerKey}", Name = "GetCustomer")]
  public async Task<IHttpActionResult> GetCustomer(string customerKey)
  {
    // ... Stateless method implementation.       
  }
}

Because this article is an end-to-end overview of Azure Service Fabric and microservices, we won’t go through further steps to implement OWIN into your Service Fabric microservice. There’s a simple example available on GitHub that you can download and analyze (bit.ly/1OW5Bmj): Web API and Service Fabric HelloWorld Example (ASP.NET 4.x).

Implement Self-Hosting with ASP.NET 5 Web API

Running ASP.NET 5 on top of Azure Service Fabric is the best fit for building microservices because Service Fabric lets you deploy any number of services into each node/VM, which allows for high microservices density per cluster. ASP.NET 5 also provides exciting features such as the following:

  • Flexible hosting: You can now host your ASP.NET 5 application on IIS or in your own process. Hosting in your own process is fundamental in Azure Service Fabric.
  • Web API, MVC and Web Pages: These are all merged together, simplifying the number of concepts.
  • Full side-by-side support: ASP.NET 5 applications can now be installed on a machine without affecting any other applications on the machine that might be using a different .NET Framework version. This is a huge feature for IT management.
  • Cross-platform support: ASP.NET 5 runs and is supported on Windows, Mac OS X and Linux.
  • Cloud-ready: Features such as diagnostics, session state, cache and configuration are designed to work locally and in the cloud (like Azure) with no changes.

Looking forward, high-density capability will get even better when Service Fabric eventually delivers .NET Core 5 and CoreCLR support.

While support for .NET Core and CoreCLR remains in the works for Service Fabric, the benefit when that support comes online is clear. Running ASP.NET 5 on top of .NET Core 5 provides a lightweight .NET framework and CoreCLR runtime with a very small memory footprint compared to the traditional .NET 4.x. That combination will enable incredible microservices density, as shown in the “Microservice B” panel in Figure 7.

Comparing ASP.NET 5 Running on the CLR vs. CoreCLR Within the Service Fabric Context
Figure 7 Comparing ASP.NET 5 Running on the CLR vs. CoreCLR Within the Service Fabric Context

While .NET Core 5 and CoreCLR support is a future option, enterprises can prepare for it today by developing ASP.NET 5 services on top of .NET 4.x on Service Fabric. Doing so will make it easier to migrate to the CoreCLR in the future.

Operating and Deploying Hyper-Scale Microservices

The operations and deployment management provided by Service Fabric are other reasons why it’s great for building and running in production hyper-scale microservices. You can focus on micro­services development and let Service Fabric provide all the complex plumbing under the hood.

The high density of microservices is a great benefit if you care about lowering infrastructure cost. A Service Fabric cluster is composed of a pool of many VMs/servers (and containers in the future) called nodes in the cluster. In each node Service Fabric automatically deploys several services, so depending on the power of each server/VM you can have a super-high density of micro­services across your cluster.

In Azure Service Fabric you have the ability to run hundreds of service instances on each machine or VM. That provides great savings for your Total Cost of Ownership (TCO). For the same amount of services, you’ll need less hardware. Therefore, high density is a big differentiator when comparing Azure Service Fabric with Azure Cloud Services, where you’re limited to one VM per Service. If you were deploying microservices as a Web Role or Worker Role you probably had too many resources assigned to a single microservice, yielding slowdowns when deploying and managing. For instance, in Figure 8 you can see one VM per instance of service in the form of Azure Web Role or Worker Role (color indicates type of service while each shape or box indicates a different VM and service instance). This approach doesn’t help if you’re looking to have high density of microservices, unless you use small VMs. Still, there’s a limit and you won’t be able to reach the same level of high density in either deployment compared to Azure Service Fabric.

Services Density Comparison—Azure Cloud Services vs. Service Fabric
Figure 8 Services Density Comparison—Azure Cloud Services vs. Service Fabric

By contrast, in Service Fabric you can deploy any number of microservices per node, so the density of services is far more efficient and cost is reduced. You can have tens, hundreds or even thousands of VMs/servers per cluster, with tens or hundreds of microservice instances and replicas per node/VM. And because each microservice is simply a process, the deployment and scaling is a lot faster than creating a new VM per service, as is the case with Azure cloud services.

Creating a Cluster in Azure’s Cloud Before deploying micro­services, you need to create the cluster of nodes in Azure or on-premises servers. When creating the cluster in the Azure cloud (like your production or staging environment), you can work directly from the Azure Portal or using Azure Resource Manager (ARM). In Figure 9, you see a Service Fabric cluster we created in our Azure Subscription by using the Azure Portal. Under the hood, the cluster creation process is based on Azure ARM and Azure Resource Groups. In this case, we created a cluster with five nodes/VMs that are also placed within an Azure Resource Group.

Service Fabric Cluster in the Azure Portal
Figure 9 Service Fabric Cluster in the Azure Portal

Deploying Applications/Services to the Cluster Once the cluster of nodes/VMs is up and running, you can deploy services. When deploying to production clusters you usually use a Windows PowerShell script to deploy your apps/services to the cluster in Azure, although for staging/test environments you can also deploy directly from Visual Studio.

When deploying to a local cluster on your development PC using Visual Studio 2015, you would usually deploy directly from the IDE by right-clicking on the Service Fabric application project and selecting Deploy. You can also use Windows PowerShell to deploy to the development cluster in your laptop, because the same Service Fabric bits run in development clusters as in Azure cloud-based clusters.

Day-to-day operations and manageability of deployments is necessary to keep services running smoothly in the long run, and application lifecycle management features have been built into Service Fabric, keeping the microservices-based approach in mind. The operations and management features available in Service Fabric include fast deployments, zero-downtime application upgrades, health monitoring of the services, and cluster scale up and scale down. Zero-downtime upgrades are possible because the upgrade tech in Service Fabric provides a built-in combination of rolling upgrades and automatic health checks that detect and roll back the changes in the upgrade if they destabilize the application. Management of Service Fabric clusters and applications is possible through Windows Powershell commands, providing all the power of the CLI and scripting, while also supporting visual tools including Visual Studio for ease of use.

Rolling upgrades are performed in stages. At each stage, the upgrade is applied to a subset of nodes in the cluster, called an upgrade domain. As a result, the application remains available throughout the upgrade. You can also have strong versioning and side-by-side support so you can deploy v1 and v2 versions of the same microservice and Service Fabric will redirect to one or the other, depending on the client’s requests. Check the documentation at bit.ly/1kSupz8 for further details.

When debugging services within your local development cluster within your PC, Visual Studio makes it simple even when the services’ processes are already running  before you start debugging. The IDE automatically attaches to all the microservices processes related to your project, making it easy to get started and use the regular breakpoints in your Service Fabric  microservices code. Just set the breakpoints in your code and hit F5. You don’t need to find out to what process you need to attach Visual Studio.

Service Fabric Explorer Service Fabric Explorer, depicted in Figure 10, is a Web-based tool provided by the cluster to visualize the state of deployed applications, inspect the contents of individual nodes and perform various administrative actions. The Explorer tool is served from the same HTTP Gateway service that supports the Service Fabric REST APIs and can be reached by navigating to https://<your-cluster-endpoint>:19007/Explorer. In the case of a local cluster, the URL would be https://localhost:19007/Explorer.

The Service Fabric Explorer
Figure 10 The Service Fabric Explorer

For further details on Service Fabric Explorer, read the documentation page, “Visualizing Your Cluster Using Service Fabric Explorer” (bit.ly/1MUNyad).

The Service Fabric platform enables a range of features that allow you to focus on application development rather than implementing complex health and upgradable systems. Among them:

Scaling out Stateless Services The Service Fabric orchestration engine can automatically scale your Web app across more machines whenever new nodes are added to a cluster. When creating instances of a stateless service, you can specify the number of instances you want to create. Service Fabric will place that number of instances on nodes in the cluster accordingly, making sure not to create more than one instance on any one node. You can also instruct Service Fabric to always create an instance on every node by specifying “-1” for the instance count. This guarantees that whenever you add nodes to scale out your cluster, an instance of your stateless service will be created on the new nodes.

Automatic Resource Balancing Service Fabric provides service resource balancing (or service orchestration) that understands the total available resources in the cluster (like the compute from the VMs). It automatically moves the microservices depending on defined policies and constraints to best optimize how the created services are placed across the Vms (see Figure 11). This is focused on optimizing costs and performance.

Cluster Showing Services Distribution Across the Nodes and Automatic Resource Balancing
Figure 11 Cluster Showing Services Distribution Across the Nodes and Automatic Resource Balancing

Built-in Failover and ReplicationMachines in any datacenter or public clouds are prone to unplanned hardware failures. To guard against such scenarios Service Fabric provides built-in failover and replication, which means that despite hardware problems the availability of services is not affected. This is possible because Service Fabric can run and manage multiple instances of each service across machines and failure domains.

Placement Constraints You can instruct the cluster to do things like not place the front-end microservices in the same machines/nodes as the middle-tier microservices, and to avoid collocating certain types of microservices in the same nodes. This can be done to minimize known conflicts or to ensure priority access to resources for certain microservices.

Load Balancing of Requests Not to be confused with automatic resource balancing, load balancing requests are not handled by Service Fabric, but rather by the Azure Load Balancers or other platform external to Service Fabric.

Health Allows you to monitor and diagnose your systems. Also used during application upgrades to provide safety checks so upgrades can be rolled back if the upgrade has a destabilizing effect. For more information, see the documentation page, “Introduction to Service Fabric Health Monitoring” (bit.ly/1jSvmHB).

Stateful Microservices in Azure Service Fabric

Support for stateful services is an exciting and important component of Azure Service Fabric. It’s also complex and wide-ranging enough that exploring stateful services goes beyond the scope of this article, but we’ll briefly explain what it is. Look for a follow-on article focused on this area of Service Fabric in a future issue.

A stateful microservice in Service Fabric collocates compute and data, with the state placed within the microservice itself (both in-memory and persisted on local disk). The reliability of state is achieved through local persistence and replication of data to other nodes/VMs. Basically, each data partition has several replica services associated with it. Each replica can be deployed in a different node/VM to provide high availability should the primary replica go down. This is similar to how Azure SQL Database works with database replicas, because it’s based on Azure Service Fabric.

In complex and scalable applications, stateful services simplifies the architecture and reduces the number of components compared to a traditional, three-tier architecture that needs to use external cache and queues. When using stateful services, the benefits of a traditional external cache is now intrinsic in the stateful service. Additionally, external queues aren’t needed because we can imple­ment internal queues within the Service Fabric microservices.

When using stateful services, it automatically creates hot backup secondaries that can pick up the operations from the same point where a primary left off following a hardware failure. Many times services have to scale to continue to meet the demands of a growing user base, requiring the addition of hardware to the running environment. Service Fabric uses features such as partitioning so that services can be built in a way that they automatically spread over onto new hardware without requiring user intervention.

Stateful Azure Reliable Services provide a host of capabilities, including data partition support, replica support and leader election, replica service naming, and service address discovery from the gateway service. It also provides management of concurrency and granularity of state changes using transactions, the ability to maintain consistent state replication, and the use of reliable, distributed key/value collections (Reliable Dictionary and Reliable Queue). The good news is that Service Fabric handles the complexity and details of these topics for you, so you can focus on writing applications.

Reliable Actors Services in Azure Service Fabric

Azure Service Fabric Reliable Actors is an actor programming model for Service Fabric. It provides an asynchronous, single-threaded actor model. An actor represents a unit of state and computation. In some ways it’s similar to the open source software project “Orleans” created by Microsoft Research. The important point is that Service Fabric Reliable Actors API is based on the underlying infrastructure provided by Service Fabric.

Implementing actor-instances for Internet of Things (IoT) devices is a good example of actor services usage. A Vehicle-Actor type in the form of a C# class would encapsulate the IoT vehicle domain logic plus its live states like GPS coordinates and other data. Then, we would have potentially millions of actor objects or instances of that mentioned class, distributed across many nodes in the cluster.

Of course, actors are not limited to live IoT objects­—they could be used for any subject, but “live IoT objects” is a great didactic scenario.

Actors are distributed throughout the cluster to achieve high scalability and availability and are treated as in-memory objects in every cluster’s VM. They are also persisted on local disk and replicated through the cluster.

The actors are isolated single-threaded objects that encapsulate both state and behavior. Every actor is an instance of an actor type, similar to the .NET code shown here:

// Actor definition (State+Behaviour) to run in the back end.
// Object instances of this Actor class will be running transparently
// in the service back end.
public class VehicleActor : Actor<Vehicle>, IVehicleActor
{
  public void UpdateGpsPosition(GpsCoordinates coord)
  { 
    // Update coordinates and trigger any data processing
    // through the State property on the base class Actor<TState>.
    this.State.Position= coord;
  }
}

Next, the following code shows example client code to use the actor via a proxy object:

// Client .NET code
ActorId actorId = ActorId.NewId();
string applicationName = "fabric:/IoTVehiclesActorApp";
IVehicleActor vehicleActorProxy =
  ActorProxy.Create<IVehicleActor>(actorId, applicationName);
vehicleActorProxy.UpdateGpsPosition(new GpsCoordinates(40.748440, -73.984559));

All the communication infrastructure is taken care of under the hood by the Service Fabric Reliable Actors framework.

You could have millions of VehicleActor objects running on your cluster across many different nodes/VMs, and Service Fabric would be taking care of the required plumbing, including partitions and replicas where your millions of actors are spread and balanced.

The Actors client API provides communication between an actor instance and an actor client. To communicate with an actor, a client creates an actor proxy object that implements the actor interface. The client interacts with the actor by invoking methods on the proxy object.

For the scenarios where actors fit, it greatly simplifies the microservices implementation, especially when compared to stateful reliable services where you have more control but need to implement a lot of plumbing related to partitioning data, partition addressing, replicas and the like. If you don’t need fine-grain control, then you can avoid the extra work by using Reliable Actors.

Wrapping Up

Microservices architectures require a commitment to decentralized approaches, disciplined architecture and design processes, new technologies like Azure Service Fabric, and a change in team dynamics toward small development teams and Agile principles applied per microservice.

Cesar de la Torre is a senior program manager at Microsoft and lives in Redmond, Wash. His interests include Microsoft Azure and .NET development with approaches such as microservices architectures and domain-driven design, as well as mobile apps development surfacing the services.

Kunal Deep Singh is a senior program manager on the Microsoft Azure Service Fabric team. Prior to Azure he worked on multiple releases of Windows Phone, Silverlight and as a game developer for Xbox titles. He lives in Seattle, Wash.

Vaclav Turecek is a senior program manager at Microsoft. He works tirelessly with a very talented group of people to make Azure Service Fabric the best next-­generation Platform as a Service.

Thanks to the following Microsoft technical expert for co-authoring and reviewing this article: Mark Fussell
Mark Fussell is passionate about building cloud-scale applications, having spent many years at Microsoft creating products ranging from data access and communications to other server-side technologies. He is excited to see that Microsoft has made Service Fabric available to everyone for building applications with a microservices approach.