Service Fabric Application
To understand how Service Fabric handles resource scheduling, it is important to understand the concept of an application in Service Fabric. A Service Fabric application is a collection of constituent services. Each service consists of code, configuration, and data packages that implement the functionality of that particular service, which is illustrated in Figure 8.5.
Application Manifest
An application is defined through its manifest file. At the time of writing, the application manifest is a definition file authored by the application developer, which describes the physical layout, or package, of a Service Fabric application. The application manifest references the service manifests of the constituent services from which the application is composed. From a conceptual point, the application manifest can be compared to the docker-compose.yml file, which is used to define and run multicontainer applications with Docker. In addition to referencing the services in an application, developers can use the application manifest to configure the “run-as” policy as well as the “security access” (that is, read/write-on resources) for each imported service when the application is instantiated. This is typically very useful to control and restrict access of services to different resources to minimize any potential security risk.
Service Manifest
The services referenced in the application manifest are defined through a service manifest authored by the service developer. The service manifest specifies independently upgradable code, configuration, and data packages that together implement a specified set of services that can then be run in the cluster once it is deployed.
The service manifest is used to define what service or containers need to be executed, what data belongs to a service, what endpoints to expose, and so on, which is very similar to a Dockerfile where developers define OS, frameworks, code, and endpoints to build a Docker image which is used for a container. In the service manifest, developers can configure additional things like service types (stateful or stateless), load metrics, and placement constraints.
Note
With placement constraints, developers can make sure that services or containers are only placed on a certain node type. Node types can be configured in the ARM templates and contain the name of the node type and its hardware configurations. A good example is that developers can make sure that their web services only run on nodes that are tagged with the node type “webservers.” The nodes of type “webserver” could be based on virtual machines with a hardware configuration optimized for web server workloads.
See https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-model/ for more information on application and service configuration.
Once the application is running, Service Fabric starts automatically resource-balancing the services across the underlying shared pool of cluster nodes to achieve the optimal load distribution, based on a set of load metrics using the services available in the Hosting subsystem. In case of a node failure, Service Fabric moves the services that were running on that node onto the remaining nodes. The placement happens based on available resources and service metrics. Another great functionality of Service Fabric is that it rebalances the services across the cluster in the case of scale-out in a cluster. We will learn more details about that later in the chapter when we look at stateful services.