Azure Service Fabric Knowledge Base

A curated list of helpful material to start learning Modern Development Things :smile:

Project Workflow using ZenHub

Title	Author	Version	Group	Sub-Levels
Azure Service Fabric Knowledge base	dtro-devuk	1.0	Root	0

Azure Service Fabric is a Platform-as-a-Service offering, which promises us a way to build highly reliable, massively scalable cloud based services

Service Fabric comes in different flavours catering to different requirements.
There are two APIs available to us,
1. Reliable Actors and
2. Reliable Service(s) API’s,
and the services we build can be either stateful or stateless.

Advantages of Service Fabric and Microservices

Create independently deployable microservices: easier to deploy than n-tier architectures
Autonomous experimental teams: allows creation of nimble, teams that can deliver functionality quicker.
Leverage a cloud platform: minimize writing plumbing code, and maximize feature development, allowing the teams to ship more customer features.

Taken from benefits to TalkTalk TV…

Agility: Rolling upgrades, granular versioning, packaging and deployment to achieve faster delivery cycles and maintain uptime during upgrades.
Development environment and programming models: Developers able to build and run the solutions locally using the Service Fabric SDK using a combination of the reliable actors and reliable services programming models.
Scalability: The granularity of service scaling and versioning enables the system to scale as the number of users, devices, and content grows.

Actors are single-threaded objects capturing logic and state
All Actors considered stateful
Each maps a unique ID (repeated calls to same ID routed to same instance)
Can maintain state reliably using persistence and replication (after failures, outages, reactivation, garbage collection) or when moved around nodes, depends on how state is persisted:
1. Persisted State (to disk and up to 3+ replicas, most durable and handles complete outage)
2. Volatile State (kept only in memory and replicated to 3+ replicas (not disk so if all replicas lose then state is lost)
3. No persisted state (not replicated or written to disk)
Each one simply a configuration for the Reliable Stateful Service, whether written depends on the state provider and replica count.
Set via an attribute on the Actor
State objects requested asynchronously directly from memory and cached on first call

see:

By default, the state is persistent to disks (in addition to replication to 3 nodes), so it should survive the restarts.
Pressing F5 in Visual Studio, the default behavior is to delete your old application and deploy the current version as a new application.
To maintain the state on your dev cluster, you can tick a checkbox in project properties to do upgrades instead of clean deployments.
You have the same options when deploying to Azure - deploy a new app (and lose the state) or deploy an upgrade to persist the state.
The old and new versions of your state class should be compatible, they are based on DataContract to make it a bit easier.

**NB. State Clears on Restart!!!

Local clusters begin eating up your SD drive, so you can tweak config and locations of data and logs using the notes below:

.\DevClusterSetup.ps1 -PathToClusterDataRoot -PathToClusterLogRoot

.\DevClusterSetup.ps1 -PathToClusterDataRoot d:\SfDevCluster\data -PathToClusterLogRoot d:\SfDevCluster\log

Open MS Powershell as Administrator
Eleveate permissions: Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser
Navigate to ClusterSetup folder: cd “C:\Program Files\Microsoft SDKs\Service Fabric\ClusterSetup”
Run command to move partitions to d drive: .\DevClusterSetup.ps1 -PathToClusterDataRoot d:\SfDevCluster\data -PathToClusterLogRoot d:\SfDevCluster\log