Service fabric projects in separate git repos

Question

Following a normal microservices framework we would like to place each microservice in it's own git repo and then have one repository for the Service Fabric project. When we update one of the microservice the though would be that the Service Fabric project would redeploy just that service.

Is there any examples of splitting the Service Fabric project up like this? I've noticed in all of their examples everything is in one solution/repository.

Answer 1

tl;dr: Figure out what best works for your development team(s) in terms of managing code and releases of individual services. Use diff packages to upgrade only changes in your Service Fabric applications. Smallest repo size should be one Service Fabric Application contained in one Visual Studio Solution.

Longer version: It is fully possible to split your Service Fabric Application into multiple applications, the smallest being one Service Fabric Application for each microservice you have. If this is a good idea or not completely depends on the type of application you are trying to build. Are there any dependecies between the services? How do you partition services and could there be any scenario when you want to do that in a coordinated maner? How are you planning to monitor your services? If you wan't to do that in a coordinated maner then again it might make sense to have more services in the same application.

Splitting the code into repos that are smaller than your Visual Studio solution would likely only lead to trouble for you. You could technically work with Git submodules or subtrees to some effect, but the way Visual Studio handles project references inside solutions would likely make you end up in merge-hell very soon.

When it comes to upgrading your Service Fabric Application there is actually a way for you to upgrade only the changed services in your application based on the version numbers in the service manifest. This is called a diff package and can be used to deploy an application to a cluster where that application has been deployed at least once (i.e. it is an upgrade, not install). This could greatly affect the upgrade time of your deployment if you have only upgrade a minority of the services in the application. The full documentation for this can be found here. There is also a SO answer that describes it.

I would say that your choice is, as much in development, a trade-off between different gains.

Splitting the services into more fine grained application containing fewer service could make upgrades easier (but this effect could to some extent technically also be achieved by using diff packages). The downside of this approach is that you would have to manage dependencies as strict interfaces between your services. One approach for that would be to publish your service/actor interfaces to a private NuGet-feed. This in turn introduces some additional complexity in your development pipeline.

Keeping everything in the same repo, same Visual Studio solution, same Service Fabric Application could work for smaller solutions but will likely be hard to work with in the long run if your solution grows in terms of merges, versioning and releases.

Answer 2

With our projects we follow a pattern similar to this, but not that fine grained. Each SF Application is contained in it's own repo, but we'll have multiple specific microservices in an application. We separate our applications into specific pieces of functionality in respect to the end application (Data Tier, Middle Tier, Presentation, Analytics, etc). When we upgrade we'll upgrade specific applications at a time, not necessarily specific services. Upgrading specific services is a huge pita ops wise. We still have a shared interfaces project and we use SF remoting to communicate between the different applications and we are able to do that because we manage containers and interfaces in its own repo that we then distribute via a private nuget server. This makes things difficult workflow wise but in the end it's nice because it makes us remain aware of interface compatibility between applications. We also have some core microservices that every application will have which we distribute using SF Nuget. It's still young and has some sharp edges, but it's awesome.