Azure Service Fabric

4 min readMay 15, 2020

Service Fabric is a core of Microsoft Azure Cloud, which enables many more services such as Cosmos DB, SQL Server, Cortana, and others, but also allows you to build our own back ends based on Microsoft’s years of rich experience.

Before starting getting in to Azure Service Fabric, let’s see how it differs from Kubernetes:

Programming Models

In general, there are four different approaches to create a microservice in Service Fabric.

1. Reliable Service:

Reliable Services are the easiest way to start with Service Fabric as they’re somewhat similar and sometimes identical to a usual Windows service or a Linux daemon application. Example : console application

You won’t be forced to use any of Service Fabric specific API and can benefit from the same tools. Reliable Services are subdivided into subtypes. There are

Stateless services: which in many ways look and act like a console application,
and Stateful microservices: which are a state‑of‑the‑art, self‑contained microservices with its own transactional replicated storage.

which in many ways look and act like a console application, and stateful microservices, which are a state‑of‑the‑art, self‑contained microservices with its own transactional replicated storage.

Service Lifecycle:

2. Actor Model

What is problem with Traditional Programming model?

Modern computers have many CPU cores, and an application is using just a single CPU, and the code executing in it is known to run on the primary thread. If we need to utilize full power of your current hardware, traditionally, we would spawn another thread or as many threads as required. This is all fine, however, this classic approach does have its problems, and there are many of them due to the fact things are now running in parallel, and tasks running on different threads may have dependencies on each other.

What is an Actor?

An actor is an isolated entity and is defined as a fundamental unit of computation, which embodies three essential parts: processing, storage, and communications. Here is one of the nice video by Carl Hewitt:

https://www.youtube.com/watch?v=7erJ1DV_Tlo

Actor can only process one message at a time. Essentially, it runs on a single thread, takes a message from the queue, processes it, returns the result, and repeats the process until there are more messages available.

For a developer, this means that we don’t have to worry about multithreading anymore as the code runs on a single thread as effectively as it can. But then how does this help to use machine resources effectively? Well, instead of sending a message to one actor, you can create three actors and send them different messages.

Actors are cheap, you can create them, as many as we like; therefore, if we change our approach to something like this, there is a chance that the system will execute them in parallel. The main thing we should remember is that multiple actors can run parallelly, but one actor processes messages sequentially. The underlying actor runtime implementation makes sure it executes actors as effectively as possible so you don’t have to worry about parallelism.

Simulating Disasters

There are two primary methods you can use to easily test our services for disasters.

Service Fabric Explorer.
Controlled chaos in Service Fabric clusters : This service produces random events for a specific period of time, which include restarting a node, restart a deployed code package, remove replica, restart replica, and others.

Transactions

A transaction is a sequence of operations performed as a single logical unit of work. Transaction is based on ACID concept: Atomicity, Consistency, Isolation, Durability.

Actor State Management:

Only reliable dictionaries, one instance per actor.
Automatic transaction management.
State reliability and Scalability

Setting up Volume for Docker Container:

Containers do not have anything special in string state. Just like with a typical application, we need external storage, like SQL Server, NoSQL DB, Blob Storage, and so on. However, some applications cannot rely on this, especially if they were designed to store state on local disk. However, Docker has some solution to this called volumes. Volumes allow you to mount a virtual folder on disk.