This is a bit descriptive so please bear with me. :)
In the application that I'm trying to build, there are distinct functionalities of product. Users can choose to opt-in for functionality A, B, D but not C. The way I'm building this, is that each of the distinct functionality is a Service (stateless, I'm thinking of storing the data in Azure SQL DBs and exposing REST APIs from each service). Bundled all services together is an ApplicationType. For each customer tenant (consider this as an shared account of a group of users) that is created, I'm thinking of creating a new concrete instance of registered ApplicationType using a TenantManagementService and calling client.ApplicationManager.CreateApplicationAsync() on a FabricClient instance so that I can have a dedicated application instance running on my nodes for that tenant. However, as I mentioned, a tenant can choose to opt-in only for specific functionality which is mapped to a subset of services. If a tenant chooses only service A of my Application, rest of the service instances corresponding to features B, C, D shouldn't be idly running on the nodes.
I thought of creating actors for each service, but the services I'm creating are stateless and I'd like to have multiple instances of them actively running on multiple nodes to load balance rather than having idle replicas of stateful services.
Similar to what I'm doing with application types, i.e., spawning application types as a new tenant registers, can I spawn/delete services as and when a tenant wants to opt-in/out of product features?
Here's what I've tried:
I tried setting InstanceCount 0 for the services at when packaging my application. In my ApplicationParameters XML files:
<Parameters>
<Parameter Name="FeatureAService_InstanceCount" Value="0" />
<Parameter Name="FeatureBService_InstanceCount" Value="0" />
</Parameters>
However, Service Fabric Explorer cribs when instantiating the application out of such application type. The error is this:
But on the other hand, when a service is deployed on the fabric, it gives me an option to delete it specifically, so this scenario should be valid.
Any suggestions are welcome!
EDIT: My requirement is similar to the approach mentioned by anderso in here - https://stackoverflow.com/a/35248349/1842699, However, the problem that I'm specifically trying to solve is to upload create an application instance with one or more packaged services having zero instance count!
#uplnCloud
I hope I understand everything right.
Your situation is the following:
Each customer should have separate Application (created from the same ApplicationType).
Each customer should have only subset of Services (defined in ApplicationType).
If I get it right then this is supported out of the box.
First of all you should remove <DefaultServices /> section from the ApplicationManifest.xml. This will instruct Service Fabric to don't create services automatically with the application.
Now the algorithm is the following:
Create application using FabricClient.ApplicationManager.CreateApplicationAsync()
For each required feature create a new corresponding Service using FabricClient.ServiceManager.CreateServiceAsync() (you need to specify the Application name of newly created Application)
Also note that CreateServiceAsync() accepts ServiceDescriptor that you can configure all service related parameters - starting from partitioning schema and ending up with instance count.
Unfortunately you can't have 0 instance services, Service Fabric has the idea that a named service always exists(running). In this case, when you define a service (give a name to a serviceType instance), it will have at least 1 instance running, otherwise, you shouldn't even have the definition of this service on your application if it does not need to be running.
But what you can have is the ServiceType definition, that means, you have the binaries but you will create it when required.
I assume you are being limited by the default services, where you declare the application and services structure upfront(before deployment of any application instance), instead, you should use dynamic service creation via FabricClient like you described, or via Powershell using New-ServiceFabricApplication and New-ServiceFabricService .
This link you guide you how to do it using FabricClient
I'll just add this as a new answer instead of commenting on another answer.
As other have mentioed, remove DefaultServices from your ApplicationManifest. That way, every new instance of the ApplicationType you create will come online without services, and you'll have to create those manually depending on what functionallity your customer has selected.
Also, going with the "services per customer" approach, make sure you got enough nodes to handle the load when you get customers online. You'll end up with a lot of processes (since Application Instances) runs their own processes of the services, and if you have few nodes with a lot of these, reboots to your cluster nodes can take a bit to stabilise since it can potentionally have many services it needs to relocate. Altough running Stateless Services will aleviate a good part of this.
Related
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.
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)?
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.
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.
Resource governance is configured in the service manifest, not at the instance level.
I’m designing my service fabric cluster. I’m between creating one app and hosting all the services inside vs creating 1 app per service.
I didnt find clear guidelines on this. The main advantage I see for 1 app per service is that we can deploy each service independently since it has its own app. We can also host the code in different repos. Are there downsides for this?
A better approach is to have one Application per set of services where the services provide a cohesive function. An Application should be an umbrella for n number of services which are related in their function, for instance they may be within the same bounded context or be related to a common operational unit. However, this doesn't mean they have to be deployed / updated in unison.
Services can be deployed independently within an ApplicationType if you move away from using the DefaultServices construct. You can read about why Default Services should be avoided in Production here - essentially they create a rigid deployment strategy and you lose some of the power of Service Fabric parameterization available via PowerShell.
The concept of an Application may seem at odds with a Microservice architecture, but remember its just a logical grouping, single services within an Application are still independently deployable.
Lots of useful info in the Application Model docs.
The main advantage I see for 1 app per service is that we can deploy each service independently since it has its own app.
You can also deploy\upgrade individual services in same application without affecting the other deployed services. Please check about differential packaging here and here
We can also host the code in different repos
Generally when we split our code into separate repositories is because we have a domain boundary that we don't want to track with other services, for example, services owned by different teams or deployed on different schedule, in this case would make sense to have them as separate applications.
Are there downsides for this?
Technically, no. But there are some possible points you have to keep in mind.
When we talk about Microservices we see them as independent services running on their own with as few dependency as possible on other services, when we talk about applications we kinda go against this 'law', because we have to deploy them together, we shouldn't see applications that way, because the applications is just a logical isolation for these services, so where is the benefit on SF applications?
When you have multiple services deployed (dependent or not on each other), you need a way to keep track of them as a bigger unit, otherwise you might end with:
a cluster full of services that sometimes are not required anymore, and is just there because we 'might be using them' or someone forgot to remove when their peers got obsolete.
Dependent services missing on new deployments
Version of services not compatible with each other (contracts, APIs, and so on)
SF Applications works like a snapshot of these services, so for example, whenever a new service get updated, you also upgrade the application to reference the new definition of your services and their dependencies, this will tell SF "this is how I want my services running" and SF will manage to get them exactly as you described. Does not mean you have to update all of them when a upgrade is required, SF will do if you have to, but you can update just the ones that changed, and them deploy a version of your application that SF will manage the version of each service for you. An analogy, it is like a docker compose file where you specify the containers you have to deploy as a single deployment.
Given that, when you opt out of application concept, you loose these benefits, because now you have to manage every single service on their own and keep track of the versions they depend on, and in cases where two services on different applications need to be deployed together (because of breaking changes for example) you would not be able to easily rollback if one of them fail, because they are not dependent on each other anymore, so you would have to write your own logic to handle this.
A typical scenario you might find yourself in is where a new version of a service get updated and others not updated on same release might stop working, but for your deployment, the new service looks OK, without any error.
So, at the end, is just a trade off, you opt for more flexibility deploying your service, but end up with more maintenance.
What is the reasoning behind Applications concept in Service Fabric? What is the recommended relation between Applications and Services? In which scenarios do Applications prove useful?
Here is a nice summary how logical services differ from physical services: https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/logical-versus-physical-architecture
Now, in relation to Service Fabric, Service Fabric applications represent logical services while Service Fabric services represent physical services. To simplify it, a Service Fabric application is a deployment unit, so you would put there multiple services that rely on the same persistent storage or have other inter-dependencies so that you really need to deploy them together. If you have totally independent services, you would put them into different Service Fabric applications.
An application is a collection of constituent services that perform a certain function or functions. 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. Each component in this hierarchical application model can be versioned and upgraded independently.
It is described here in detail
How I currently see it, applications are a nice concept to group multiple services together and manage them as single unit. In context of service fabric, this is useful if you have multiple nano-services which do not warrant them being completely standalone; instead you can package them together into microservices (SF application).
Disclaimers:
- nano-service would be a REALLY small piece of code running as a stateless SF service for example (e.g. read from queue, couple of lines of code to process, write to another queue).
- in case of "normal" microservices, one could consider packaging them as 1 SF application = 1 SF service
An application is a required top level container for services. You deploy applications, not services. So you cannot really speak about differences between the two since you cannot have services without an application.
From https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-application-model:
An application is a collection of constituent services that perform a certain function or functions. A service performs a complete and standalone function (it can start and run independently of other services) and 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. Each component in this hierarchical application model can be versioned and upgraded independently.
Take a look at the link provided and you will see the hierarchical relationship.
I need help how to think about designing our application to fit into the new Azure Service Fabric template.
Today we have an application built on Azure Cloud Services. The application is built around DDD and we have separate bounded contexts for different subsystem parts of the application. The bounded contexts are today hosted in one worker role that exposes these subsystems using a single WebAPI.
Additionally we have one Web Role hosting the web frontend and one Worker Role processing a background queue.
We strive to move to a micro services architecture. The first thing I planned to do was to extract all bounded context into their own API-hosts. This will result in 5-10 new WebAPI services supporting our subsystems.
To my question, should all of these subsystem/bounded context/API-hosts be their own Service Fabric Application or a service within a single Service Fabric Application?
I've read the documentation, found here Service Fabric Application Model, over and over and I can't figure out where my services fits in.
We want the system to support different versions of the services, and the services should also be possible to scale different from another. There might even be a requirement to have one micro service to run in a larger VM size then the rest.
Please can someone guide me in which suits my needs.
I think you have the right idea, in general terms, that each bounded context is a (micro) service. Service Fabric gives you two levels of organization with applications and services, where an application is a logical grouping of services. Here's what that means for you:
Logically speaking, think of an application as a cohesive set of functionality. The services that collectively form that cohesive set of functionality should be grouped as an application. You can ask yourself, for each service: "does it make sense to deploy this service by itself without these other services?" If the answer is no, then they should probably be grouped in the same application.
Developmentally speaking, the Visual Studio tooling is geared a bit more toward multiple services in one application, but you can have multiple applications in one solution too.
Operationally speaking, an application represents a process boundary, upgrade group, and versioning group:
Each instance of an application you create gets its own process (or set of processes if you have multiple service types in the application). Service instances of a service type share host processes. Service instances of different service types get their own process per type.
The application is the top level upgrade unit, that is, every upgrade you do is an application upgrade. You can upgrade individual services within an application (you don't always have to upgrade every service within an application), but each time you do an upgrade, the application version changes.
You can create side-by-side instances of different versions of the same application type in your cluster. You cannot create side-by-side instances of different versions of the same service type within an application instance.
Placement and scale is done at the service. So for example, you can scale one service in an application, and you can place another service on a larger VM.
I need to to deploy 2 different worker role instances but each needs it's own configuration data (ID code, password, SenderCompID, etc.) to connect to a trading server. I can't share the credentials across the instances.
Each instance for any role (Worker or Web) are identical in terms of application based configuration. This is because all the instances are created from the same application will read exact same application configuration data.
If you write your application in a way that when application starts it reads data outside the machine (from azure storage, azure table or anything else outside the VM, mostly available on some server) and then configure itself then you could achieve your objective. You also need to provide instance specific data on server so each instance gets its own data. If I choose this option, i might use Azure table name i.e. Instance_ID# so each instance gets its own configuration and configured itself. This way I can modify the data any time on Azure Table and restart the role to load updated configuration. Other may have some other way to make it happen.
The other option is to have two role (worker or web) in same Azure application and while application code could be same in between two or more worker roles however you sure can configure them separately. Each of above options have its own pros and con.