The case for Azure Service Fabric.

The world is currently going towards Containers and everybody's favorite Container Orchestrator is Kubernetes aka K8s.
This article shows that K8's is not the only framework for building Distributed apps, especially on Windows Server and how Service Fabric also has a few advantages over Kubernetes!

Before we get started, Service Fabric gives all of these benefits out of the box.

Service Fabric can be installed on your laptop to hundreds (and thousands) of machines spanning multiple locations on the planet. The run time and SDK are free and can be enabled via "Azure Development workload" in Visual Studio Installer.

Steps

• Enable "Azure Development workload" via the Visual Studio installer
• Install Service SDK from https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started
• If you need to deploy containers, you need to install Docker.
• Open Visual Studio, create your first service fabric application
• 
• Choose the "Project Type" you want to start with. You can have a "Stateful Service", "Stateless Service", "Actor Service", ASP.Net Core [Both Stateful and Stateless] & Container Hosted Project.
• 
• After choosing your first project type, enter your " project name" and click "Next". Below you can see that I've created a "Stateful" service called "ProductService"
• 

Post Installation of SDK

• After the SDK is installed, you will see a service fabric icon in the system tray.
• 
• You have the option of creating a "5 node" or "1 node" local cluster. "1 Node" is better for faster deployments. "5 node" more closely mimics a production cluster.
  • You can manage the local service fabric dev cluster using the local service fabric explorer. [default URL: http://localhost:19080/]
  • 

Anatomy of a Service Fabric Application

• Our Service Fabric Application name is "Dev_To_SF".

• The project "Dev_To_SF.csproj" is the Service Project "glue" project that holds references to all other fabric projects. The job of dev_To_SF.csproj is to...

  • Define the "ApplicationManifest.xml", "AplicationParameters" and "PublishProfiles" file. ApplicationManifest file lists the service types, partition types [for stateful services], Package Reference names, Package Version Numbers and Default App parameters
  • "ApplicationParameters" folder houses the "params" that are to be passed when the Application is being constructed in Service Fabric. [You may have different set of params based on Dev/UAT/Prod environments]
  • Publish Profiles folder defines the profile to be used when deploying to a particular envt.
  • The scripts folder contains a Powershell script that is invoked when deploying from Visual Studio. For localhost deployments this is fine. For CI/CD, you would want to use Azure DevOps Server/Jenkins etc as your build tool for automated deployments.
  • The "Default Services" section in ApplicationManifest defines what services to be installed by default in your cluster. If you want fine grained control, you can omit this section and deploy your app using Powershell commands. This approach gives you total flexibility on what "services types" to create under your application.

Anatomy of a Microservice inside a Service Fabric Application

• "Product Service" is a Stateful service. The entry point for this service is inside "Program.cs" in ProductService. This entry point resembles a console application because it is! It uses service fabric specific API's to to register "ProductService" with the fabric runtime.
• Each service also has a "ServiceManifest" file that describes http/tcp end points names, service versions etc and Settings file that defines any service specific params.
• The stateful Product service class inherits "StatefulService" class. This gives us accesss to the "StateManager" instance which is responsible for propagating the app state to the "Primary" and "Secondary" replicas.
• The internal" StateManager" gives access to a "Key-Value" store which models a regular .Net Dictionary but which is different and built for the cloud.

Coming Next..

• In the next article, we will look @ deployment to local cluster, Stateful Services and a little bit more on Reliable Dictionaries.

I mentioned in the beginning of the article that Service Fabric has some advantages over Kubernetes.. here they are:

• Service Fabric orchestrates both Processes and Containers. Kubernetes is strictly a "Container" Orchestrator. The barrier to entry into Service Fabric is lower. Process Orchestration has the fastest activation times.
• Service Fabric provides a reliable services programming model on top of the core "Orchestrator". This programming is what gives us reliable services, actor model, queues etc.
• Equal support to windows and linux containers. Kubernetes services are linux first. If your primary deployment target is windows server, you will be slightly behind in terms of features.
• Learning curve: There are many tools and add-ons available in the kubernetes world. On the service fabric side, The default installer will give all you need to develop your first micro service app and deploy it. I believe developing and deploying to service fabric cluster is easier compared to Kubernetes.

Side Note: We got a 50% performance boost moving our windows service workload to a 10 node service fabric cluster on similar hardware! [On-Premises]