My Introduction into Azure Service Fabric
I was challenged by my CEO to learn something more about Azure Service Fabric technology. Let me show you what I learned.
Azure Service Fabric is a platform created by Microsoft that facilitates creating and deploying microservice-based architecture systems. It provides scalability, reliability, and availability for your system.
Microservice Architecture
If you want to use Azure Service Fabric, first you must understand what microservice architecture represents.
Microservice architecture is based on multiple independent applications(services), which are communicating mostly via their public API. Service should not see implementation details of other services and vice versa. Microservices provide scalability by design because the system load is divided into more “subsystems”.
Systems like these are harder to maintain than monolithic based systems because the developer must think a little bit differently than he was used to. Every service is a self-based system that should run by itself without relying on other systems.
Cluster
Every Azure Service Fabric project is made of things called Cluster. Cluster is a bulk of resources (Load balancer, applications, IP addresses) needed for the correct functioning of an application. Cluster is made of so-called Nodes.
Node
Nodes are nothing more than usual computers or virtual machines. They use an operating system such as Windows or Linux and have installed an Azure Service Fabric Runtime. The cluster can contain 1:N nodes. These nodes are connected to each other in a network-based communication.
The main purpose of the node is to host your application. One node could host multiple applications which means every cluster can host unlimited amounts of applications, as long as there are physical resources up to it.
Application
The result of the Azure Service Fabric solution is an application. An application is nothing more than a declaration of what does solution contains. An application describes which services it contains.
Stateful and Stateless service
Stateless service is, as the title hints, a service without any state. Simply speaking, stateless service does not have any storage to save the state of data. A stateless service can be also understood as a project with a database connection. How is it possible?
A project with a database connection is not storing data. The database is storing data. Storing data means saving the state.
On the other hand, the Stateful service can store data in special so-called Reliable Collections. I will provide more information about the reliable collection in the next article.
Actor service
As a special kind of Stateful service performs Actor service. Actor service is a service based on the Actor Model. The Actor Model is not a product of Azure Fabric Service and it is not invented by Microsoft either. The Actor Model Theory is a simplification of multithreading programming. You can find detailed information about the Actor Model here.
How I think about Actor service is that there are multiple instances of service with your own storage per unit that you desire. For example, one user of your application can have his instance of Actor service.
Every Actor service must be provided with identification. It may be string, it may be Guid, etc. If it can be string, it can be mostly every casted primitive type of variable you want to use.
If you think about it you can find out, that it can nicely handle one too many relationships between entities. If there is always one instance of service per user ID, there is also dedicated storage for one user. It is one too many relationships solved at the virtual or physical machine level.
So instead of creating queries using the where clause with user ID condition you just create an instance of the whole service. And that is what I find very powerful as a developer.
