service-fabric

Service Fabric is a distributed systems platform for packaging, deploying, and managing stateless and stateful distributed applications and containers at large scale.

3,020

399

3,020

828

View on GitHub

Top Related Projects

azure-sdk-for-net

5,245

This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.

aks-engine

1,027

AKS Engine: legacy tool for Kubernetes on Azure (see status)

orleans

10,029

Cloud Native application framework for .NET

nomad

14,765

Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.

Quick Overview

Service Fabric is an open-source distributed systems platform developed by Microsoft. It enables developers to build and manage scalable and reliable microservices and containerized applications for cloud and on-premises environments. Service Fabric provides a comprehensive runtime and lifecycle management capabilities for both stateless and stateful services.

Pros

Supports both Windows and Linux environments, offering flexibility in deployment options
Provides built-in support for stateful services, simplifying the development of complex distributed applications
Offers automatic scaling, self-healing, and rolling upgrades, enhancing application reliability and maintainability
Integrates well with other Azure services and supports various programming models (e.g., Reliable Services, Reliable Actors)

Cons

Steep learning curve for developers new to distributed systems and microservices architecture
Limited adoption outside of Microsoft ecosystem compared to other container orchestration platforms like Kubernetes
Documentation can be complex and overwhelming for beginners
Some features and tooling are primarily focused on Windows, potentially limiting Linux users

Getting Started

To get started with Service Fabric, follow these steps:

Install the Service Fabric SDK and runtime:

# For Windows (using PowerShell)
Install-Module -Name ServiceFabric -AllowClobber

# For Linux (Ubuntu)
wget https://apt.servicefabric.io/public.key
sudo apt-key add public.key
sudo bash -c 'echo "deb [arch=amd64] https://apt.servicefabric.io/ xenial main" > /etc/apt/sources.list.d/servicefabric.list'
sudo apt-get update
sudo apt-get install servicefabricsdkcommon

Create a new Service Fabric application:

# Using Visual Studio (Windows)
# Create a new project and select "Service Fabric Application" template

# Using Yeoman generator (Linux)
npm install -g yo generator-azuresfjava
yo azuresfjava

Build and deploy your application:

# Using Visual Studio (Windows)
# Right-click on the project and select "Publish"

# Using Service Fabric CLI (sfctl)
sfctl cluster select --endpoint http://localhost:19080
sfctl application upload --path MyApplication
sfctl application provision --application-type-build-path MyApplication
sfctl application create --app-name fabric:/MyApp --app-type MyApplicationType --app-version 1.0.0

For more detailed instructions and advanced scenarios, refer to the official Service Fabric documentation.

Competitor Comparisons

azure-sdk-for-net

5,245

Pros of azure-sdk-for-net

Broader scope, covering multiple Azure services
More frequent updates and active development
Extensive documentation and samples

Cons of azure-sdk-for-net

Larger codebase, potentially more complex to navigate
May include unnecessary dependencies for specific use cases
Steeper learning curve for developers new to Azure

Code Comparison

service-fabric:

using System.Fabric;
using Microsoft.ServiceFabric.Services.Communication.Runtime;
using Microsoft.ServiceFabric.Services.Runtime;

internal sealed class MyStatelessService : StatelessService
{
    protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
    {
        // Service-specific implementation
    }
}

azure-sdk-for-net:

using Azure.Storage.Blobs;
using Azure.Identity;

BlobServiceClient blobServiceClient = new BlobServiceClient(
    new Uri("https://your-storage-account.blob.core.windows.net"),
    new DefaultAzureCredential());

BlobContainerClient containerClient = blobServiceClient.GetBlobContainerClient("sample-container");
await containerClient.CreateIfNotExistsAsync();

The service-fabric example focuses on creating a stateless service, while the azure-sdk-for-net example demonstrates interacting with Azure Blob Storage. The azure-sdk-for-net provides a more generalized approach to working with various Azure services, whereas service-fabric is specifically designed for building and managing microservices applications.

aks-engine

1,027

AKS Engine: legacy tool for Kubernetes on Azure (see status)

Pros of aks-engine

Focused on Kubernetes deployment and management in Azure
Supports multiple Kubernetes versions and customizations
Easier to integrate with existing Kubernetes ecosystems

Cons of aks-engine

Limited to Kubernetes orchestration
Requires more manual configuration for advanced scenarios
Less integrated with Azure-specific services compared to Service Fabric

Code Comparison

aks-engine (Kubernetes manifest):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app

Service Fabric (application manifest):

<ApplicationManifest ApplicationTypeName="MyAppType" ApplicationTypeVersion="1.0.0">
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="MyServicePkg" ServiceManifestVersion="1.0.0" />
  </ServiceManifestImport>
</ApplicationManifest>

aks-engine focuses on Kubernetes-native deployment definitions, while Service Fabric uses its own XML-based manifest format for defining applications and services. aks-engine provides more flexibility for Kubernetes-specific deployments, whereas Service Fabric offers tighter integration with Azure services and a more opinionated approach to application architecture.

orleans

10,029

Cloud Native application framework for .NET

Pros of Orleans

Simpler programming model with virtual actor abstraction
Easier to scale and manage distributed applications
More flexible deployment options (on-premises, cloud, hybrid)

Cons of Orleans

Less mature ecosystem compared to Service Fabric
Limited built-in support for stateful services
Steeper learning curve for developers new to actor-based programming

Code Comparison

Orleans:

public class MyGrain : Grain, IMyGrain
{
    public Task<string> SayHello(string greeting)
    {
        return Task.FromResult($"Hello, {greeting}!");
    }
}

Service Fabric:

public class MyStatelessService : StatelessService
{
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {
        while (true)
        {
            cancellationToken.ThrowIfCancellationRequested();
            await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
        }
    }
}

Orleans focuses on the virtual actor model, making it easier to develop distributed systems with a more straightforward programming model. Service Fabric provides a more comprehensive platform for building and managing microservices, offering both stateless and stateful services out of the box. While Orleans offers greater flexibility in deployment options, Service Fabric has a more mature ecosystem and better support for stateful services. The choice between the two depends on specific project requirements and team expertise.

nomad

14,765

Pros of Nomad

Simpler architecture and easier to set up and manage
More flexible, supporting a wider range of workloads (containers, VMs, binaries)
Better support for multi-region and multi-cloud deployments

Cons of Nomad

Less mature ecosystem compared to Service Fabric
Fewer built-in features for microservices and stateful services
Limited support for Windows workloads

Code Comparison

Nomad job specification:

job "web" {
  datacenters = ["dc1"]
  type = "service"
  group "frontend" {
    count = 3
    task "nginx" {
      driver = "docker"
      config {
        image = "nginx:latest"
      }
    }
  }
}

Service Fabric application manifest:

<ApplicationManifest ApplicationTypeName="WebApp" ApplicationTypeVersion="1.0.0">
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="WebServicePkg" ServiceManifestVersion="1.0.0" />
  </ServiceManifestImport>
  <DefaultServices>
    <Service Name="WebService">
      <StatelessService ServiceTypeName="WebServiceType" InstanceCount="3">
        <SingletonPartition />
      </StatelessService>
    </Service>
  </DefaultServices>
</ApplicationManifest>

Both examples define a simple web service with three instances, but Nomad uses HCL syntax while Service Fabric uses XML. Nomad's configuration is more concise and focuses on the deployment aspects, while Service Fabric's manifest provides more detailed service definitions and application structure.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Service Fabric

Service Fabric is a distributed systems platform for packaging, deploying, and managing stateless and stateful distributed applications and containers at large scale. Service Fabric runs on Windows and Linux, on any cloud, any datacenter, across geographic regions, or on your laptop.Service Fabric represents the next-generation platform for building and managing these enterprise-class, tier-1, cloud-scale applications running in containers.

Architecture and Subsystem Explorer

Learn about Service Fabric's Core Subsystems, mapped to this repo's folder structure.

Service Fabric release schedule

Here is the upcoming release schedule for Service Fabric runtime versions that we will be supporting starting with version 8.0.

Version	Release date
8.0	2021 Mar
8.1	2021 Jul
8.2	2021 Oct
9.0	2022 Apr
9.1	2022 Oct
10.0	2023 Apr
10.1	2023 Nov

Please note that these dates are advanced estimates and might be subject to change or minor adjustments closer to each release.

We will be publishing upcoming features and roadmap items on Azure Updates for Service Fabric.

Repo status

We are in the process to move our development to GitHub. Until then, the Service Fabric team will continue regular feature development internally. We'll be providing frequent updates here and on our team blog as we make progress.

Quick look at our current status

Service Fabric build tools for Linux
Basic tests for Linux builds available
Container image with build tools available to run builds

Providing feedback and filing issues

We have multiple repositories (in addition to this one) that constitute the Service Fabric product. For more information on how to provide feedback and file issues across the different components (and associated repositories), please see Contributing.md.

Build Requirements

The requirements below are based off running clean builds using ninja, with the command

runbuild.sh âc ân

The builds were run on Azure Linux VMs with added disk capacity. If you want to to build on an Azure machine you need to add approximately 70GB for the source+build outputs.

These times should be taken as estimates of how long a build will take.

Machine SKU	Cores	Memory	Build Time
Standard_D8s_v3	8	32GB	~4 hours
Standard_D16s_v3	16	64GB	~2 hours
Standard_D32s_v3	32	128GB	~1 hour

On a smaller VM (Standard_D4s_V3 / 4 cores / 16GB) the build may fail. You may be able to build on a machine with less RAM if you limit the parallelism using the -j switch.

The build also requires approximately 70GB of disk space.

Setting up for build

Get a Linux machine

This is the Linux version of Service Fabric. You need a Linux machine to build this project. If you already have a Linux machine, great! You can get started below. If not, you can get a Linux machine on Azure.

Installing docker

Our build environment depends on Docker. In order to get started you will need to install docker.

There are many ways to install docker. Here is how to install on Ubuntu:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt-get update
sudo apt-get install -y docker-ce

Optional: Enable executing docker without sudo

By default docker requires root privelages to run. In order to run docker as a regular user (i.e, not root), you need to add the user to the docker user group:

sudo usermod -aG docker ${USER}
su - ${USER}

You do not need to do this, but note that if you skip this step, you must run all docker commands with sudo.

Build Service Fabric

To start the build inside of a docker container you can clone the repository and run this command from the root directory:


./runbuild.sh

This will do a full build of the project with the output being placed into the out directory. For more options see runbuild.sh -h.

Additionally in order to build and create the installer packages you can pass in the -createinstaller option to the script:

./runbuild.sh -createinstaller

Optional: Build the container locally

If you would prefer to build the container locally, you can run the following script:

sudo ./tools/builddocker.sh

Currently, the build container is based off a base image that includes a few Service Fabric dependencies that have either not yet been open sourced, or must be included due to technical constraints (for example, some .NET files currently only build on Windows, but are required for a Linux build).

This will pull all of the required packages, add Service Fabric internal dependencies, and apply patches.

Troubleshooting: Internet connectivity when installing local docker containers behind a firewall

A common issue with building a docker container behind a firewall is when the firewall blocks the default DNS used by docker. This will manifest as packages failing to download during the docker build step (such as in the builddocker.sh script above).

To fix this, you need to tell Docker to use an alternative DNS server. As a root user, create or edit the Docker daemon's config file at /etc/docker/daemon.json so that it has an entry that looks like this:

{ 
    "dns": ["<my DNS server IP here>", "<my DNS secondary server IP here>"] 
}

Take note to replace the above command with your actual local DNS server, and restart docker:

service docker restart

Testing a local cluster

For more details please refer to Testing using ClusterDeployer.

Running a local cluster

For more details please refer Deploying local cluster from build

Documentation

Service Fabric conceptual and reference documentation is available at docs.microsoft.com/azure/service-fabric. Documentation is also open to your contribution on GitHub at github.com/Microsoft/azure-docs.

Samples

For Service Fabric sample code, check out the Azure Code Sample gallery or go straight to Azure-Samples on GitHub.

Channel 9: Inside Azure Service Fabric

Take a virtual tour with us and meet some of the folks who design and implement service fabric. This Channel 9 YouTube playlist will continue to grow over time with content describing the inner workings of Service Fabric. We have covered most of the subsystems already.

LicenseÂ

All Service Fabric open source projects are licensed under the MIT License.

Code of ConductÂ

All Service Fabric open source projects adopt the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot