Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices. Service Fabric also addresses the significant challenges in developing and managing cloud applications. Developers and administrators can avoid solving complex infrastructure problems and focus instead on implementing mission-critical, demanding workloads knowing that they are scalable, reliable, and manageable. Service Fabric represents the next-generation middleware platform for building and managing these enterprise-class, Tier-1 cloud-scale applications

1. Develop and operate distributed applications, scalable and always available
SERVICE FABRIC
OCT. 2016 – MICHEL BRUCHET - ARCHITECT

2. P a g e 2
Agenda
Tell me about
Service Fabric
Get started
Build an
application
Service Fabric
clusters on
Azure
Standalone
Service Fabric
clusters
Test services
Application
upgrades
Scale

3. P a g e 3
Tell me about Service Fabric
Tell me about
Service Fabric
Overview of
Service fabric
Wat are a
microservices?
Where can you
use Service
fabric?

4. P a g e 4
Overview of Service Fabric
Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and
reliable microservices. Service Fabric also addresses the significant challenges in developing and managing cloud
applications. Developers and administrators can avoid solving complex infrastructure problems and focus instead on
implementing mission-critical, demanding workloads knowing that they are scalable, reliable, and manageable.
Service Fabric represents the next-generation middleware platform for building and managing these enterprise-
class, Tier-1 cloud-scale applications

5. P a g e 5
What is a microservice?
here are different definitions of microservices, and searching the Internet provides many good resources that
provide their own viewpoints and definitions. However, most of the following characteristics of microservices are
widely agreed upon:
• Encapsulate a customer or business scenario. What is the problem you are solving?
• Developed by a small engineering team.
• Written in any programming language and use any framework.
• Consist of code and (optionally) state, both of which are independently versioned, deployed, and scaled.
• Interact with other microservices over well-defined interfaces and protocols.
• Have unique names (URLs) used to resolve their location.
• Remain consistent and available in the presence of failures.
You can summarize these characteristics into:
Microservices applications are composed of small, independently versioned, and scalable customer-focused
services that communicate with each other over standard protocols with well-defined interfaces.

6. P a g e 6
Comparison between application development approaches
1. A monolithic app contains domain-specific functionality and is normally divided by functional layers, such as web,
business, and data.
2. You scale a monolithic app by cloning it on multiple servers/VMs/containers.
3. A microservice application separates functionality into separate smaller services.
4. This approach scales out by deploying each service independently, creating instances of these services across
servers/VMs/container

7. P a g e 7
State storage between application styles
1. On the left is the monolithic approach, with a single database and tiers of specific technologies.
2. On the right is the microservices approach, a graph of interconnected microservices where state is
typically scoped to the microservice and various technologies are used.

8. P a g e 8
Where can we use Service Fabric?
Run in Azure, on-premises, or in other clouds
Enjoy the flexibility to deploy the same application code on
public, hosted, or private clouds using consistent platform
services and the same application model across Azure, on-
premises, and hosted datacenters. With Microsoft's commitment
to a choice and flexibility, your service fabric application can run
on Azure, on-premises and in other clouds with a choice of
Windows Server or Linux as the host operating system

9. P a g e 9
What main states of service can you build?
Service State
There are two main states of services you can build with
Service Fabric:
•Stateless Services - no state is maintained in the service.
Longer term state is stored in an external database. This is
your typical application/data layer approach to building
services that you are already likely familiar with.
•Stateful Services - state is stored with the service. Allows
for state to be persisted with out the need for an external
database. Data is co-located with the code that is running the
service.

10. P a g e 10
What types of porgramming models can you build?
Once you have decided whether you are building a Stateful or Stateless service you can then choose
from multiple types of programming models to help you build you services:
•Guest - allows you to run any executable inside Service Fabric runtime. This can be an executable or a
container
•Reliable Services - light weight framework that lets you integrate with the Service Fabric runtime (can
be stateful or stateless)
•Reliable Actor - framework that lets you build your applications using the Actor pattern (can be stateful
or stateless)

11. P a g e 11
Stateless Application Use Cases
Typical use cases for a Stateless Application are:
•web interface for end users
•API gateway to other services
•proxies
•existing stateless service
•calculations that don’t require state (complex
math calculations where all state is provided and a
result is returned)

12. P a g e 12
Stateless Service Fabric Programming Models
The Service Fabric Programming model that you might use depends on the specific use case. A few guiding
tips:
•Guest Executable - There are a few scenarios where using an existing application make sense. Existing
applications that are moving over to Service Fabric is a great use case. Another use case would be team
familiarity with a language or the particular external service (data store or service) that is part of the system
has better first class support for a language that doesn’t have an Service Fabric Runtime API currently. With
a Guest Executable you get the advantages like service orchestration and rolling upgrades but miss out on
being able to tie into the more advance features that service fabric platform has to offer such as custom
health reporting.
•Stateless Reliable Services - Use Stateless Reliable Services when you are building new services from
scratch and want to take advantage of the Service Fabric platform features. By using the Reliable Services
API’s you get access to the features like health monitoring, endpoint registration, load reporting and more.
Any application endpoints built using ASP.NET Core (MVC or WebAPI) are great use cases for Reliable
Services. A Java Reliable Services API is in the works

13. P a g e 13
Statefull Application Use Cases
Typical use cases for a Stateful application are:
•any data service (such as order service or inventory
service)
•gaming scenarios
•most services where data is stored externally and
pulled into do processing (you would model it so the
data is local)
•data analytics and workflows

14. P a g e 14
Stateful Service Fabric Programming Models
The Service Fabric Programming model that you might use depends on the specific use case. A few guiding
tips:
•Stateful Reliable Services - allows the most flexibility around the managing state. It allows you create
transactions around multiple data types or create complex processing units of work. Most Stateful services can
be created using this programming model and is a great place to start if you are sure your domain doesn’t fit
the Actor Model.
•Stateful Actor Model - This model is useful anytime the Actor pattern can be used to describe your domain
space. This sounds obvious but is only useful if you know where you might use the Actor model to model your
domain space. A few scenario’s would be where you are doing a high number of small, independent
calculations or have many concurrent interactions that need supervision. Understanding the Actor model is
outside the scope of this post. If you are not familiar with the Actor model I would recommend learning a little bit
more so you can be sure to leverage this powerful programming model inside Service Fabric when appropriate.
Another important note is the the level of reliability at which a Actor stores state can be configured. They can be
configured to store the state as persisted, volatile, and only in memory.

15. P a g e 15
The Actor pattern
The Actor model adopts the philosophy
that everything is an actor. This is similar to
the everything is an object philosophy used by
some object-oriented programming languages.
An actor is a computational entity that, in response to
a message it receives, can concurrently:
•send a finite number of messages to other actors;
•create a finite number of new actors;
•designate the behavior to be used for the next
message it receives.
There is no assumed sequence to the above actions
and they could be carried out in parallel.
Decoupling the sender from communications sent
was a fundamental advance of the Actor model
enabling asynchronous communication and control
structures as patterns of passing messages.

16. P a g e 16
Get Started
Get Started
Create your first
service fabric
application
Create a local
cluster and
deploy it
Setup your
development
environment

17. P a g e 17
Setup your development environment
Supported operating system versions
The following operating system versions are supported for development:
•Windows 7
•Windows 8/Windows 8.1
•Windows Server 2012 R2
•Windows 10
1. Install the runtime, SDK, and tools
2. Enable PowerShell script execution
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser

18. P a g e 18
Create your first Azure Service Fabric application
1.Launch Visual Studio as an
administrator.
2.Click File > New Project > Cloud >
Service Fabric Application.
3.Name the application and click OK.

19. P a g e 19
Choose your application type
On the next page, choose Stateful as the
first service type to include in your
application. Name it and click OK.

20. P a g e 20
Solution explorer
The application project does not contain any code directly. Instead, it
references a set of service projects. In addition, it contains three other
types of content:
•Publish profiles: Used to manage tooling preferences for different
environments.
•Scripts: Includes a PowerShell script for deploying/upgrading your
application. Visual Studio uses the script behind-the-scenes by Visual
Studio. The script can also be invoked directly at the command line.
•Application definition: Includes the application manifest
under ApplicationPackageRoot. Associated application parameter
files are under ApplicationParameters, which define the application
and allow you to configure it specifically for a given environment.
Press F5 in Visual Studio to deploy the application for debugging.

21. P a g e 21
Deploy and debug the application
Now that you have an application, try running it.
Press F5 in Visual Studio to deploy the application for debugging.
Note:
Deploying takes a while the first time, as Visual Studio is creating a local cluster for development. A local cluster
runs the same platform code that you will build on in a multi-machine cluster, just on a single machine. The cluster
creation status displays in the Visual Studio output window.
When the cluster is ready, you will get a notification from the local cluster system tray manager application
included with the SDK.

22. P a g e 22
Diagnostics Event Viewer
Once the application starts, Visual Studio automatically
brings up the Diagnostics Event Viewer, where you can
see trace output from the service
In the case of the stateful service template, the messages simply show the counter value incrementing in
the RunAsync method of MyStatefulService.cs.
Expand one of the events to see more details, including
the node where the code is running. In this case, it is
_Node_2, though it may differ on your machine
The local cluster contains five nodes hosted on a single machine. It mimics a five-node
cluster, where nodes are on distinct machines. Let's take down one of the nodes on the
local cluster in order to simulate the loss of a machine while exercising the Visual Studio
debugger at the same time.

23. P a g e 23
Access Service fabric local dashboard
Service Fabric Explorer offers a visual representation of a cluster-
-including the set of applications deployed to it and the set of
physical nodes that make it up. To learn more about Service
Fabric Explorer, see Visualizing your cluster.

24. P a g e 24
Simulate a machine restart
1.In the left pane, expand Cluster > Nodes and
find the node where your code is running.
2.Click Actions > Deactivate (Restart) to
simulate a machine restarting. (Note you can also
deactivate from the context menu in the node list
view in the left pane.)
Return to the Diagnostic Events Viewer and observe the
messages. Note that the counter has continued incrementing, even
though the events are actually coming from a different node

25. P a g e 25
Switch cluster mode
By default, the local development cluster is configured to run as a 5 node cluster which is useful for debugging
services deployed across multiple nodes. Deploying an application to the 5 node development cluster can take
some time, however. If you want to iterate code changes quickly, without running your app on 5 nodes, you can
switch the development cluster to 1-Node mode. To run your code on a cluster with one node, right-click on the
Local Cluster Manager in the system tray and select Switch Cluster Mode -> 1 Node.

26. P a g e 26
Cleaning up
1.To shut down the cluster but keep the application data and traces, click Stop Local Cluster in the
system tray app.
2.To delete the cluster entirely, click Remove Local Cluster in the system tray app. Note that this option
will result in another slow deployment the next time you press F5 in Visual Studio. Delete the cluster only
if you don't intend to use the local cluster for some time or if you need to reclaim resources.

27. P a g e 27
Get started with deploying and upgrading applications on your
local cluster
It is important to understand that the Service Fabric local cluster is not an emulator or simulator. It runs
the same platform code that is found on multi-machine clusters. The only difference is that it runs the
platform processes that are normally spread across five machines on one machine
1. Launch a new PowerShell window as an administrator.
2. Run the cluster setup script from the SDK folder:
& "$ENV:ProgramFilesMicrosoft SDKsService FabricClusterSetupDevClusterSetup.ps1"

28. P a g e 28
Deploy an application
The Service Fabric SDK includes a rich set of frameworks and developer tooling for creating applications
1.Launch a new PowerShell window as an administrator.
2.Import the Service Fabric SDK PowerShell module
Import-Module "$ENV:ProgramFilesMicrosoft SDKsService
FabricToolsPSModuleServiceFabricSDKServiceFabricSDK.psm1"
3. Create a directory to store the application that you download and deploy, such as
C:ServiceFabric.
mkdir c:devServiceFabric
cd c:devServiceFabric
4. Connect to the local cluster:
Connect-ServiceFabricCluster
localhost:19000
5. Create a new application using the SDK's deployment command with a name and a path to the
application package.
Publish-NewServiceFabricApplication -ApplicationPackagePath C:devServiceFabricWordCountV1.sfpkg -
ApplicationName "fabric:/WordCount"
6. To see the application in action, launch the browser and navigate http://localhost:8081/wordcount/index.html.

29. P a g e 29
View application details and status
1. Query all deployed applications on the cluster
Get-
ServiceFabricApplication
2. Go to the next level by querying the set of services that are included in the WordCount
application.
Get-ServiceFabricService -ApplicationName 'fabric:/WordCount'
3. Finally, take a look at the list of partitions for WordCountService
Get-ServiceFabricPartition 'fabric:/WordCount/WordCountService'
For a more visual way to interact with the cluster, you
can use the web-based Service Fabric Explorer tool by
navigating to http://localhost:19080/Explorer in the
browser.

30. P a g e 30
Upgrade an application
Service Fabric provides no-downtime upgrades by monitoring the health of the
application as it rolls out across the cluster.
Let's perform a simple upgrade of the WordCount application.
The new version of the application now counts only words that begin with a vowel. As the upgrade rolls out, we see
two changes in the application's behavior. First, the rate at which the count grows should slow, since fewer words
are being counted. Second, since the first partition has two vowels (A and E) and all other partitions contain only
one each, its count should eventually start to outpace the others.
Return to your PowerShell window and use the SDK's upgrade command to register the new version in the
cluster. Then begin upgrading the fabric:/WordCount application
Publish-UpgradedServiceFabricApplication -ApplicationPackagePath C:devServiceFabricWordCountV2.sfpkg -
ApplicationName "fabric:/WordCount" -UpgradeParameters @{"FailureAction"="Rollback";
"UpgradeReplicaSetCheckTimeout"=1; "Monitored"=$true; "Force"=$true}
http://localhost:19080/Explorer/index.html#/
Get-ServiceFabricService -ApplicationName
'fabric:/WordCount'http://localhost:8081/wordcount/index.html.

31. P a g e 31
Cleaning up
To remove an individual application and all its data, run the following
Unpublish-ServiceFabricApplication -ApplicationName "fabric:/WordCount"
Remove-ServiceFabricApplicationType -ApplicationTypeName WordCount -ApplicationTypeVersion 2.0.0
Remove-ServiceFabricApplicationType -ApplicationTypeName WordCount -ApplicationTypeVersion 1.0.0
After deleting the application from the cluster, you can unregister versions 1.0.0 and 2.0.0 of the
WordCount application type. Deletion removes the application packages, including the code and
configuration, from the cluster's image store
http://localhost:19080/Explorer/index.html#/

32. P a g e 32
Build an application

33. P a g e 33
Model an application in Service Fabric
An application is a collection of constituent services that perform a certain function or functions. A service
performs a complete and standalone function (it can start and run independently of other services) and is
composed of code, configuration, and data. For each service, code consists of the executable binaries,
configuration consists of service settings that can be loaded at run time, and data consists of arbitrary static
data to be consumed by the service. Each component in this hierarchical application model can be
versioned and upgraded independently

34. P a g e 34
Describe an application
The application manifest declaratively describes
the application type and version. It specifies service
composition metadata such as stable names,
partitioning scheme, instance count/replication
factor, security/isolation policy, placement
constraints, configuration overrides, and constituent
service types. The load-balancing domains into
which the application is placed are also described.
Thus, an application manifest describes elements
at the application level and references one or more
service manifests to compose an application type.
Here is a simple example application manifest:

35. P a g e 35
Package an application
The application manifest, service manifest(s), and other
necessary package files must be organized in a specific
layout for deployment into a Service Fabric cluster. The
example manifests in this article would need to be organized
in the following directory structure
Use SetupEntryPoint
Typical scenarios for using SetupEntryPoint are when you need
to run an executable before the service starts or you need to
perform an operation with elevated privileges. For example:
Setting up and initializing environment variables that the
service executable needs. This is not limited to only
executables written via the Service Fabric programming
models. For example, npm.exe needs some environment
variables configured for deploying a node.js application.
Setting up access control by installing security certificates

36. P a g e 36
Build a package by using Visual Studio
If you use Visual Studio 2015 to create your application, you can use the
Package command to automatically create a package that matches the
layout described above
Test the package :
cd C:devHipInfraHipInfrapkg
Test-ServiceFabricApplicationPackage .Debug

37. P a g e 37
Deploy and remove applications
1. From Visual Studio 2015, click on publish
http://localhost:19080/Explorer/index.html#/

38. P a g e 38
Service Fabric health monitoring
The health entities are organized in a logical hierarchy that captures interactions and dependencies among different
entities. The entities and hierarchy are automatically built by the health store based on reports received from Service
Fabric components.
The health entities mirror the Service Fabric entities. (For example, health application entity matches an application
instance deployed in the cluster, while health node entity matches a Service Fabric cluster node.) The health hierarchy
captures the interactions of the system entities, and it is the basis for advanced health evaluation. You can learn about key
Service Fabric concepts in Service Fabric technical overview. For more on application, see Service Fabric application model.
The health entities and hierarchy allow the cluster and applications to be effectively reported, debugged, and monitored.
The health model provides an accurate, granular representation of the health of the many moving pieces in the cluster.

39. P a g e 39