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

Reading your question, it sounds like your repository split is mainly for deployment concerns, so I will focus on that aspect.

We are using one Git repository per Service Fabric application (which contains multiple services), this helps to simplify how Continuous Integration and Continuous deployment is done: if there is a change in the repo (code or config), the SF application needs to be build and deployed.

If you are using the Build and Releases features of VSTS online, you can easily leverage the build Tasks available for Service Fabric in order to support differential upgrades. Using the “Update Service Fabric App Versions” task (https://www.visualstudio.com/en-us/docs/build/steps/utility/service-fabric-versioning), using the “Update only if changed” option with the "deterministic compiler flag" (https://blogs.msdn.microsoft.com/dotnet/2016/04/02/whats-new-for-c-and-vb-in-visual-studio/), to make sure that binaries are always the same if code is the same, you easily end-up with differential upgrades per SF application.

Answer 2

You shouldn't necessarily think of a Service Fabric service as being a microservice.

The Service Fabric taxonomy of code/services/apps etc. gives you a high flexibility in how you compose to your needs (as already pointed out). Consider the fact that you can have more code packages running in one service and trying to translate that in to a microservice definition, just makes things even harder to cope with.

As the SF Appation is you unit of deployment (whether is contains one or more updated services), you should strive to structure your repo/solution/SF Application setup in a way so you can contain most changes to one SF App (= one solution and one repo).

If you get in a situation where you constantly need to deploy multiple SF Apps to get a change out, you will not be productive.

Answer 3

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 4

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.