Configuration and resource governance options for Azure Service Fabric stateless services?

1
votes

I am new to using Service Fabric and am trying to scope out some design options. I have a class library which performs different tasks. Some tasks are resource intensive and long-running (processing messages from queues) and others are short-lived and must be responsive (handling job requests from users). There is a significant amount of cached data so shared processes make sense, and the application is stateless. I want to make sure that long-running tasks don't starve other tasks of resources, but also that the utilisation rate is high.

  1. Is it possible to make one Stateless Service project in my solution (referencing my class library) and deploy multiple named StatelessService instances sharing the same process, using configuration to differentiate the tasks performed by those instances? With or without multiple ServiceTypes (although they seem to be one per project, so I assume this must be one ServiceType)?

  2. If so, is it possible to apply different resource governance rules to those service instances so some resources can be reserved for user-driven tasks? So far I get the impression that this isn't possible when the services share a process.

1
azureazure-service-fabric

1 Answers

3
votes
  1. The default shared process model specifies this:

The preceding section describes the default hosting model provided by Service Fabric, referred to as the Shared Process model. In this model, for a given application, only one copy of a given ServicePackage is activated on a node (which starts all the CodePackages contained in it). All the replicas of all services of a given ServiceType are placed in the CodePackage that registers that ServiceType. In other words, all the replicas of all services on a node of a given ServiceType share the same process.

You can specify multiple service types and multiple code packages.

ServiceTypes declares what service types are supported by CodePackages in this manifest. When a service is instantiated against one of these service types, all code packages declared in this manifest are activated by running their entry points. The resulting processes are expected to register the supported service types at run time. Service types are declared at the manifest level and not the code package level. So when there are multiple code packages, they are all activated whenever the system looks for any one of the declared service types.

  1. Resource governance is configured in the service manifest, not at the instance level.