Develop and operate distributed applications, scalable and always available

SERVICE FABRIC

OCT. 2016 – MICHEL BRUCHET - ARCHITECT

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

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?

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

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.

P a g e 6

Comparison between application development approaches1. 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

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.

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

P a g e 9

What main states of service can you build?

Service StateThere 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.

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)

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)

P a g e 12

Stateless Service Fabric Programming ModelsThe 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

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

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.

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.

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

P a g e 17

Setup your development environment

Supported operating system versionsThe 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 tools2. Enable PowerShell script execution

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser

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.

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.

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.

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.

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.

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.

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

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.

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.

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:ProgramFiles\Microsoft SDKs\Service Fabric\ClusterSetup\DevClusterSetup.ps1"

P a g e 28

Deploy an application

The Service Fabric SDK includes a rich set of frameworks and developer tooling for creating applications1.Launch a new PowerShell window as an administrator.

2.Import the Service Fabric SDK PowerShell moduleImport-Module "$ENV:ProgramFiles\Microsoft SDKs\Service Fabric\Tools\PSModule\ServiceFabricSDK\ServiceFabricSDK.psm1" 3. Create a directory to store the application that you download and deploy, such as C:\ServiceFabric.mkdir c:\dev\ServiceFabric\cd c:\dev\ServiceFabric\

4. Connect to the local cluster:Connect-ServiceFabricCluster localhost:190005. Create a new application using the SDK's deployment command with a name and a path to the application package.Publish-NewServiceFabricApplication -ApplicationPackagePath C:\dev\ServiceFabric\WordCountV1.sfpkg -ApplicationName "fabric:/WordCount"

6. To see the application in action, launch the browser and navigatehttp://localhost:8081/wordcount/index.html.

P a g e 29

View application details and status

1. Query all deployed applications on the clusterGet-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 WordCountServiceGet-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.

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:\dev\ServiceFabric\WordCountV2.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.

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.0Remove-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#/

P a g e 32

Build an application

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

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:

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

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:\dev\HipInfra\HipInfra\pkgTest-ServiceFabricApplicationPackage .\Debug

P a g e 37

Deploy and remove applications

1. From Visual Studio 2015, click on publish

http://localhost:19080/Explorer/index.html#/

P a g e 38

Service Fabric health monitoringThe 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.

P a g e 39