Service Fabric, The Microsoft’s Container Orchestrator

When I started working with Microsoft Service Fabric (Commonly known as Azure Service Fabric) I presumed its yet another Container Orchestrator platform like Kubernetes, Swarm & etc. However, while going through the Overview of Azure Service Fabric, things become quite unclear since it talks about Specific Programming Models and Containers Lifecycle Management in combination.

I first wondered if Service Fabric supports Containers why should they talk about a Programming Models since its none of their business whats within the Containers.Azure Service Fabric (Credits: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview)

So What is Microsoft Service Fabric?

After digging bit deep, I realized Service Fabric is not only a Container Orchestration platform that supports Docker Containers, it also provides a Service Fabric Specific Native Programming Model, where you can write Services which can run on top of the Service Fabric Platform.

Assuming you already understand about Containers (Docker), let us have a quick look at What this Programming Model is really about which is unique for Service Fabric.

Service Fabric Programming Model

Service Fabric Programming Model is more like a Service Fabric Provided Skelliton of Code (Supporting Service Fabric SDK APIs), where you fill in your business logic inside. This Skeleton code, not only acts as a starting point for the service development but also contains the metadata about how these services are placed in Service Fabric.

It appears that Microsoft has invented this model to simplify the design and development of Microservices.

Rest of the features in an Orchestration Platform, such as service discoverability, container(or service in this case) lifecycle management, health checks, load balancing & etc are provided by the Service Fabric Platform.

How Does Service Fabric Programming Model Help Microservices Development?

Service Fabric programming model currently provides support for several types of services (e.g; Stateless, Stateful, Actors & etc.). Let's say you are building a fleet of Microservices to provide several business functionalities. This requires to design each individual Microservices as well as to look at how they communicate with each other.

When I say communication, it's not just ordinary HTTP(S) communication. For instance, we need to make sure these services need to coordinate on data consistency (e.g; Once a dataset is updated on the database of a Microservice, there can be other services which require to get that update, which is traditionally being done using PubSub messaging middleware or Queues which runs on separate Containers ). Without using shared middleware Containers such as Apache Kafka for these operations, these functionalities could be built using Service Fabric Stateful Services Programming Model.

This makes things uniform using known building blocks that I see as a clear productivity improvement both for design and development of Microservices.

Should I use Service Fabric?

Technically anyone can use Service Fabric as Container Orchestration Platform. But I don’t see a clear value unless you start adopting the Service Fabric Programming Model and writing applications with .NET Core. This is where the strength of the platform comes in both for the Development and in DevOps.

I would say if you are simply planning to run Containers (e.g; Docker) go for something else like Kubernetees.

In addition, if you are building applications where the majority of services are written using other languages apart from .NET, still I feel it is better to use other platforms (Although most of these programming languages are supported by Service Fabric).

However, if you are planning to run applications in Azure as well as on-premise, Service Fabric is a go-to platform which is recommended by Microsoft.

Service Fabric, The Microsoft’s Container Orchestrator was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.