Edit

Service Fabric terminology overview

  • Article

Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices. Service Fabric is a container and process orchestrator that allows you to host your clusters anywhere: on Azure, in an on-premises datacenter, or on any cloud provider. You can use any framework to write your services and choose where to run the application from multiple environment choices. This article details the terminology used by Service Fabric to understand the terms used in the documentation.

The related training videos mentioned below detail the application, packaging, deployment, abstractions, and terminology used by Service Fabric:

Infrastructure concepts

Cluster: A network-connected set of virtual or physical machines into which your microservices are deployed and managed. Clusters can scale to thousands of machines.

Node: A machine or VM that's part of a cluster is called a node. Each node is assigned a node name (string). Nodes have characteristics, such as placement properties. Each machine or VM has an auto-start Windows service, FabricHost.exe, that starts running upon boot and then starts two executables: Fabric.exe and FabricGateway.exe. These two executables make up the node. For testing scenarios, you can host multiple nodes on a single machine or VM by running multiple instances of Fabric.exe and FabricGateway.exe.

Application and service concepts

Service Fabric Native Application: Service Fabric Native Applications are described by the Native Application Model (XML-based application and service manifests).

Service Fabric Native Application concepts

Application: An application is a collection of constituent services that perform a certain function or functions. The lifecycle of each application instance can be managed independently.

Service: A service performs a complete and standalone function and can start and run independently of other services. A service 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.

Application type: The name/version assigned to a collection of service types. It is defined in an ApplicationManifest.xml file and embedded in an application package directory. The directory is then copied to the Service Fabric cluster's image store. You can then create a named application from this application type within the cluster.

Read the Application model article for more information.

Application package: A disk directory containing the application type's ApplicationManifest.xml file. References the service packages for each service type that makes up the application type. The files in the application package directory are copied to Service Fabric cluster's image store. For example, an application package for an email application type might contain references to a queue-service package, a frontend-service package, and a database-service package.

Named application: After you copy an application package to the image store, you create an instance of the application within the cluster. You create an instance when you specify the application package's application type, by using its name or version. Each application type instance is assigned a uniform resource identifier (URI) name that looks like: "fabric:/MyNamedApp". Within a cluster, you can create multiple named applications from a single application type. You can also create named applications from different application types. Each named application is managed and versioned independently.

Service type: The name/version assigned to a service's code packages, data packages, and configuration packages. The service type is defined in the ServiceManifest.xml file and embedded in a service package directory. The service package directory is then referenced by an application package's ApplicationManifest.xml file. Within the cluster, after creating a named application, you can create a named service from one of the application type's service types. The service type's ServiceManifest.xml file describes the service.

Read the Application model article for more information.

There are two types of services:

  • Stateless: Use a stateless service when the service's persistent state is stored in an external storage service, such as Azure Storage, Azure SQL Database, or Azure Cosmos DB. Use a stateless service when the service has no persistent storage. For example, for a calculator service where values are passed to the service, a computation is performed that uses these values, and then a result is returned.
  • Stateful: Use a stateful service when you want Service Fabric to manage your service's state via its Reliable Collections or Reliable Actors programming models. When you create a named service, specify how many partitions you want to spread your state over for scalability. Also specify how many times to replicate your state across nodes, for reliability. Each named service has a single primary replica and multiple secondary replicas. You modify your named service's state when you write to the primary replica. Service Fabric then replicates this state to all the secondary replicas to keep your state in sync. Service Fabric automatically detects when a primary replica fails and promotes an existing secondary replica to a primary replica. Service Fabric then creates a new secondary replica.

Replicas or instances refer to code (and state for stateful services) of a service that's deployed and running. See Replicas and instances.

Reconfiguration refers to the process of any change in the replica set of a service. See Reconfiguration.

Service package: A disk directory containing the service type's ServiceManifest.xml file. This file references the code, static data, and configuration packages for the service type. The files in the service package directory are referenced by the application type's ApplicationManifest.xml file. For example, a service package might refer to the code, static data, and configuration packages that make up a database service.

Named service: After you create a named application, you can create an instance of one of its service types within the cluster. You specify the service type by using its name/version. Each service type instance is assigned a URI name scoped under its named application's URI. For example, if you create a "MyDatabase" named service within a "MyNamedApp" named application, the URI looks like: "fabric:/MyNamedApp/MyDatabase". Within a named application, you can create several named services. Each named service can have its own partition scheme and instance or replica counts.

Code package: A disk directory containing the service type's executable files, typically EXE/DLL files. The files in the code package directory are referenced by the service type's ServiceManifest.xml file. When you create a named service, the code package is copied to the node or nodes selected to run the named service. Then the code starts to run. There are two types of code package executables:

  • Guest executables: Executables that run as-is on the host operating system (Windows or Linux). These executables don't link to or reference any Service Fabric runtime files and therefore don't use any Service Fabric programming models. These executables are unable to use some Service Fabric features, such as the naming service for endpoint discovery. Guest executables can't report load metrics that are specific to each service instance.
  • Service host executables: Executables that use Service Fabric programming models by linking to Service Fabric runtime files, enabling Service Fabric features. For example, a named service instance can register endpoints with Service Fabric's Naming Service and can also report load metrics.

Data package: A disk directory that contains the service type's static, read-only data files, typically photo, sound, and video files. The files in the data package directory are referenced by the service type's ServiceManifest.xml file. When you create a named service, the data package is copied to the node or nodes selected to run the named service. The code starts running and can now access the data files.

Configuration package: A disk directory that contains the service type's static, read-only configuration files, typically text files. The files in the configuration package directory are referenced by the service type's ServiceManifest.xml file. When you create a named service, the files in the configuration package are copied to one or more nodes selected to run the named service. Then the code starts to run and can now access the configuration files.

Containers: By default, Service Fabric deploys and activates services as processes. Service Fabric can also deploy services in container images. Containers are a virtualization technology that abstracts the underlying operating system from applications. An application and its runtime, dependencies, and system libraries run inside a container. The container has full, private access to the container's own isolated view of the operating system constructs. Service Fabric supports Windows Server containers and Docker containers on Linux. For more information, read Service Fabric and containers.

Partition scheme: When you create a named service, you specify a partition scheme. Services with substantial amounts of state split the data across partitions, which spreads the state across the cluster's nodes. By splitting the data across partitions, your named service's state can scale. Within a partition, stateless named services have instances, whereas stateful named services have replicas. Usually, stateless named services have only one partition, because they have no internal state. The partition instances provide for availability. If one instance fails, other instances continue to operate normally, and then Service Fabric creates a new instance. Stateful named services maintain their state within replicas and each partition has its own replica set so the state is kept in sync. Should a replica fail, Service Fabric builds a new replica from the existing replicas.

Read the Partition Service Fabric reliable services article for more information.

System services

There are system services that are created in every cluster that provide the platform capabilities of Service Fabric.

Naming Service: Each Service Fabric cluster has a Naming Service, which resolves service names to a location in the cluster. You manage the service names and properties, like an internet Domain Name System (DNS) for the cluster. Clients securely communicate with any node in the cluster by using the Naming Service to resolve a service name and its location. Applications move within the cluster. For example, this can be due to failures, resource balancing, or the resizing of the cluster. You can develop services and clients that resolve the current network location. Clients obtain the actual machine IP address and port where it's currently running.

Read Communicate with services for more information on the client and service communication APIs that work with the Naming Service.

Image Store service: Each Service Fabric cluster has an Image Store service where deployed, versioned application packages are kept. Copy an application package to the Image Store and then register the application type contained within that application package. After the application type is provisioned, you create a named application from it. You can unregister an application type from the Image Store service after all its named applications have been deleted.

Read Understand the ImageStoreConnectionString setting for more information about the Image Store service.

Read the Deploy an application article for more information on deploying applications to the Image Store service.

Failover Manager service: Each Service Fabric cluster has a Failover Manager service that is responsible for the following actions:

  • Performs functions related to high availability and consistency of services.
  • Orchestrates application and cluster upgrades.
  • Interacts with other system components.

Repair Manager service: This is an optional system service that allows repair actions to be performed on a cluster in a way that is safe, automatable, and transparent. Repair manager is used in:

Deployment and application models

To deploy your services, you need to describe how they should run. Service Fabric supports three different deployment models:

Native model

The native application model provides your applications with full low-level access to Service Fabric. Applications and services are defined as registered types in XML manifest files.

The native model supports the Reliable Services and Reliable Actors frameworks, which provides access to the Service Fabric runtime APIs and cluster management APIs in C# and Java. The native model also supports arbitrary containers and executables.

Reliable Services: An API to build stateless and stateful services. Stateful services store their state in Reliable Collections, such as a dictionary or a queue. You can also plug in various communication stacks, such as Web API and Windows Communication Foundation (WCF).

Reliable Actors: An API to build stateless and stateful objects through the virtual Actor programming model. This model is useful when you have lots of independent units of computation or state. This model uses a turn-based threading model, so it's best to avoid code that calls out to other actors or services because an individual actor can't process other incoming requests until all its outbound requests are finished.

You can also run your existing applications on Service Fabric:

Containers: Service Fabric supports the deployment of Docker containers on Linux and Windows Server containers on Windows Server 2016, along with support for Hyper-V isolation mode. In the Service Fabric application model, a container represents an application host in which multiple service replicas are placed. Service Fabric can run any containers, and the scenario is similar to the guest executable scenario, where you package an existing application inside a container. In addition, you can run Service Fabric services inside containers as well.

Guest executables: You can run any type of code, such as Node.js, Python, Java, or C++ in Azure Service Fabric as a service. Service Fabric refers to these types of services as guest executables, which are treated as stateless services. The advantages to running a guest executable in a Service Fabric cluster include high availability, health monitoring, application lifecycle management, high density, and discoverability.

Read the Choose a programming model for your service article for more information.

Docker Compose

Docker Compose is part of the Docker project. Service Fabric provides limited support for deploying applications using the Docker Compose model.

Environments

Service Fabric is an open-source platform technology that several different services and products are based on. Microsoft provides the following options:

  • Azure Service Fabric: The Azure hosted Service Fabric cluster offering. It provides integration between Service Fabric and the Azure infrastructure, along with upgrade and configuration management of Service Fabric clusters.
  • Service Fabric standalone: A set of installation and configuration tools to deploy Service Fabric clusters anywhere (on-premises or on any cloud provider). Not managed by Azure.
  • Service Fabric development cluster: Provides a local development experience on Windows, Linux, or Mac for development of Service Fabric applications.

Next steps

To learn more about Service Fabric: