Azure Service Fabric

When an application is deployed, Service Fabric partitions the service (if configured) and places replicas across nodes according to placement constraints and load metrics. For stateful services, write operations must be acknowledged by a quorum of replicas (majority) before being committed. The primary replica handles all reads and writes; changes are replicated to secondary replicas. If the primary fails, the Failover Manager promotes a secondary to primary.

# Connect to cluster
Connect-ServiceFabricCluster -ConnectionEndpoint 'mycluster.westus.cloudapp.azure.com:19000'

# Get cluster health
Get-ServiceFabricClusterHealth

# Get node list
Get-ServiceFabricNode

# Get service details
Get-ServiceFabricService -ApplicationName 'fabric:/MyApp'

# Start rolling upgrade
Start-ServiceFabricApplicationUpgrade -ApplicationName 'fabric:/MyApp' -ApplicationTypeVersion '2.0' -Monitored

Azure CLI:

az sf cluster list
az sf application list --resource-group myGroup --cluster-name myCluster

During a monitored upgrade, Service Fabric: 1. Upgrades nodes in one upgrade domain at a time. 2. Waits for health check after each domain (default 30 seconds). 3. If health check fails, retries for up to 2 hours per domain, then rolls back.

class MyStatefulService : StatefulService
{
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {
        var myDictionary = await this.StateManager.GetOrAddAsync<IReliableDictionary<string, long>>("myDictionary");
        while (true)
        {
            cancellationToken.ThrowIfCancellationRequested();
            using (var tx = this.StateManager.CreateTransaction())
            {
                var result = await myDictionary.TryGetValueAsync(tx, "Counter");
                await myDictionary.SetAsync(tx, "Counter", result.HasValue ? result.Value + 1 : 0);
                await tx.CommitAsync();
            }
            await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
        }
    }
}

Enterprise Scenario 1: Financial Trading Platform A large bank uses Service Fabric to host a real-time trading engine. The application requires stateful services to maintain order books and transaction histories with low latency (sub-millisecond writes). They deploy a 50-node cluster across three availability zones, with each stateful service configured with 5 replicas for high availability. The cluster uses custom load metrics (e.g., number of open orders) to balance load. They use monitored rolling upgrades to deploy new trading algorithms without downtime. Misconfiguration example: setting MinReplicaSetSize too low (e.g., 1) caused data loss during a two-node failure; they now set it to 3. Performance consideration: partition count is set to 100 for the order book service to allow parallel processing.

Enterprise Scenario 2: IoT Device Management A manufacturing company uses Service Fabric to manage millions of IoT devices. They use Reliable Actors to represent each device, with actor state stored in Reliable Collections. The cluster has 20 nodes, each running both stateless web services (for API endpoints) and stateful actor services. They use the reverse proxy (port 19081) to route requests from the Azure Load Balancer to the correct actor. Common issue: actor garbage collection timeout (default 60 minutes) caused actors to be deactivated prematurely; they increased the timeout to 4 hours. Scale consideration: they partition actors by device ID range (uniform Int64 partitioning) to distribute load evenly.

Enterprise Scenario 3: E-Commerce Checkout Service An online retailer migrated their monolithic checkout application to Service Fabric as a set of microservices: cart service (stateful), payment service (stateless), and inventory service (stateful). They use placement constraints to ensure cart replicas run on nodes with SSDs. The cluster is managed (Azure Service Fabric managed cluster) to reduce patching overhead. They use Azure Monitor to track health and performance. A misconfiguration: initially they did not define load metrics, causing all replicas to land on a single node; they added CPU and memory metrics to balance load. They also set up autoscaling rules to add nodes during Black Friday traffic spikes.