Allow multiple configurations of the same service
We have services that are abstracted well enough that, if the ApplicationManifest allowed it, we could configure the same service with different ConfigOverrides (potentially having different instance/partition counts of each configuration) to handle different workloads. It seems the only way we can accomplish this is to essentially duplicate the entire service with a different name (yes, they can be mostly shared code via a library assembly, but this is more cumbersome than it needs to be) so that it can be imported/configured separately.
Here is a suggestion that maybe helps illustrate what I am asking for: Suppose that in the ServiceManifestRef there were more than one named ConfigOverrride, "A" and "B". If. in the DefaultServices section, we could add the same Service twice, each on referencing a different named ConfigOverride, we could easily control how many instances/partitions of that service configuration should be running.
We have workarounds, but something like this would be much more convenient.
Ryan Rogers commented
For the record, you don't have to use a library assembly, and there need not be any code duplication (unless you need it).
You can put two (or more) services in the same assembly which derived from a common abstract. The sealed services can serve as a monkier layer only. You can do this as many times as you wish.. The service registers all classes at startup. Each service therefore has it's own endpoints and config and config overrides. You can even do some trickery to get different EventSources which share the same code, but log under different EventSource names, which is beneficial, and something your requested solution would not provide.
The down-the road maintainability of this approach is not to be ignored. Need separate Startup classes if these need to diverge? No problem. Need separate event source event types? No problem. The derived class can construct these, or use a singleton, as passed into the base implementation (which doesn't care or need to know if it's shared or not).
If you are truly stuck with one service deployed multiple times, it can easily lead to a spaghetti monster with crazy stuff raised to config level just to keep everything in one code base. By using inheritance and encapsulation of an hidden implementation, you're in a much better position to manage change over time.
Hi, This suggestion is cool, would be welcome.
But you have other ways to accomplish this without duplicating the entire service as you suggested.
Are you aware that you can have multiple ConfigPackages?
You could use the default one (Config) to create the settings shared by all other 'instances', and create one for each specific service you need named as the servicename.
From you code, you could just resolve the packages using the service name:
Regarding the instanceCount and partitions, you can do the same through the defaultServices, create a copy of the service definition pointing to the same service with a different name, and use the application parameters to specify different instanceCount and partitions.
I know it is not the best solution, but can solve your problem for now.