Application per service in Service Fabric

Question

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?

Answer 1

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.

Answer 2

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.