4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

Developer Network
(https://msdn.microsoft.com/en-us)

Subscriber portal

(https://my.visualstudio.com/?wt.mc_id=o~msft~msdn~nav~subscriber&campaign=o~msft~msdn~nav~subscriber)
Get tools (https://www.visualstudio.com/free-developer-offers/)

magazine (https://msdn.microsoft.com/en-us/magazine/)
Issues and downloads Subscribe Submit article

Issues and downloads / 2015 (https://msdn.microsoft.com/en-us/magazine/mt267548.aspx) / December 2015 (https://msdn.microsoft.com/en-

us/magazine/1215mag.aspx) / Microsoft Azure - Azure Service Fabric and the Microservices Architecture (https://msdn.microsoft.com/en-
us/magazine/mt595752.aspx)

DECEMBER 2015 VOLUME 30 NUMBER 13

Microsoft Azure - Azure Service

Fabric and the Microservices
Architecture
By Cesar de la Torre (https://msdn.microsoft.com/en-us/magazine/mt149362?
author=cesar+de+la+torre), Kunal Deep Singh (https://msdn.microsoft.com/en-
us/magazine/mt149362?author=kunal+deep+singh), Vaclav Turecek
(https://msdn.microsoft.com/en-us/magazine/mt149362?author=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

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 1/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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.

Figure 1 Microservices Approach Compared to Traditional Server Application Approach

Data Sovereignty Per Microservice

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 2/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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.

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.

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 3/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 4/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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,
https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 5/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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

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

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 6/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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 (http://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 cancellationTok
{
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 Servic
await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
}
}
}
}

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 7/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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 (http://bit.ly/1UMdKIf) demonstrates how to implement this technique.

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 8/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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 CreateServiceReplicaListeners, 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 cancellationTok
{
// 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.

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 9/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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
(http://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.

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 10/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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.

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 microservices
across your cluster.

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 11/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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.

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 microservices, 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.

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 12/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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
(http://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.

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 13/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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 http://<your-cluster-endpoint>:19007/Explorer. In the case of a local cluster, the URL
would be http://localhost:19007/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 (http://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.

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 14/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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 (http://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

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 15/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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:

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 16/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

// 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

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 17/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

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.

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 18/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

MSDN Magazine Blog

(http://blogs.msdn.com/msdnmagazine/)
 

More MSDN Magazine Blog entries >

(http://blogs.msdn.com/msdnmagazine/)

Current Issue

(https://msdn.microsoft.com/en-
Browse All MSDN Magazines
us/magazine/mt833402)
(https://msdn.microsoft.com/en-
us/magazine/mt668395)

Subscribe to MSDN Flash newsletter

(https://msdn.microsoft.com/en-
us/aa570311.aspx?ocid=msdn_magazine)

Receive the MSDN Flash e-mail newsletter

every other week, with news and information
personalized to your interests and areas of
focus.

Follow us Is this page helpful? Yes Sign

No up for the MSDN Newsletter

Dev centers Learning resources Community Support

Microsoft Virtual Academy Forums Self support

Windows
(http://www.microsoftvirtualacademy.com/)
(https://social.msdn.microsoft.com/forums/en-
(https://msdn.microsoft.com/hh361695)

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 19/20
4/18/2019 Microsoft Azure - Azure Service Fabric and the Microservices Architecture

Channel 9 us/home)
Office
(http://channel9.msdn.com/) Blogs

Visual Studio MSDN Magazine (https://blogs.msdn.com/b/developer-

(https://msdn.microsoft.com/magazine/)
tools/)
Microsoft Azure Codeplex

(https://www.codeplex.com)
More...

Programs

BizSpark (for startups)

(https://bizspark.microsoft.com/Startups/Index)

Microsoft Imagine (for students)

(https://imagine.microsoft.com/)

United States (English) Newsletter (https://msdn.microsoft.com/en-us/flashnewsletter)

© 2019 Microsoft
Privacy & cookies (https://go.microsoft.com/fwlink/?LinkId=521839)
Terms of use (https://msdn.microsoft.com/en-us/cc300389)
Trademarks (https://www.microsoft.com/en-
us/legal/intellectualproperty/Trademarks/)

https://msdn.microsoft.com/en-us/magazine/mt595752.aspx 20/20