Service Fabric Subsystems
The Service Fabric system services are part of what Service Fabric calls subsystems. The major subsystems are:
• Management: The management subsystem is used to provide end-to-end service and application lifecycle capabilities, including deploying services, monitoring and diagnostics, and patching and upgrading those services without any downtime. The management subsystem can even do all the same things for Service Fabric runtime itself. Developers can use managed APIs, PowerShell commandlets, and/or HTTP APIs to access these management capabilities.
• Health: Service Fabric comes with its own health system. All components of the system such as cluster, nodes, services, and so on can report their health status. The data is stored in a centralized health store like Azure storage. Services inside of Service Fabric can also add and customize the health model by emitting custom reports into the system, which Service Fabric also utilizes alongside the built-in health properties that it understands natively.
• Communication: The most important service of this subsystem is the naming service. The naming service provides service registry and service discovery functionality within a cluster.
• Reliability: This subsystem is responsible for making sure that the services in a cluster are highly available. There are three important components in this subsystem:
The cluster resource manager, which places service/container replicas across all nodes, ensures that placement rules are enforced, and monitors and balances resource consumption.
The failover manager service, which monitors nodes and services and reacts to failures and other changes in the cluster. The Failover Manager, with the help of the Replicator and Naming, also handles leader election for stateful services (we will learn more about stateful services later in the chapter).
The Service Fabric Replicator, which ensures consistency between primary and secondary replicas for stateful services and manages quorum. We will look more closely at replicas and quorum later in the chapter.
• Federation: This subsystem is responsible for managing membership of nodes in the cluster. It provides failure detection; lease management, and node join/depart semantics.
• Transport: This subsystem is responsible for point-to-point communication within a cluster.
• Hosting: Hosting is not a real subsystem from Service Fabric’s perspective, but we are going to talk about it here for better understanding. Most of the system services in Service Fabric handle both cluster management and only service/container management. For our one-to-one comparison with Mesos, Kubernetes, Swarm, and so on, it is easier to think about some components as being responsible for hosting services and containers. Service Fabric also refers to this concept as Hosting.
Figure 8.1 shows at a high level how the Service Fabric subsystems map to a container-based solution on Azure.
If we look at all the subsystems, it becomes clear why Microsoft positions Service Fabric as a platform for building microservices. Service Fabric not only offers full cluster and service or container management, but it also offers a full programming model for developers to leverage if they want. For the remainder of the chapter, we will have a closer look at cluster management, service and container management, and the programming model.