Service Fabric Concept, Guidelines and Patterns #1
this is the first post in series which focus on Service Fabric.
the series covers Service Fabric’s concept, guidelines and common patterns.
What is Service Fabric?
Service Fabric is new framework that can operate either on the cloud (Azure) or on premise.
this framework enable to build solution from small parts (concept known as Micro-Services).
Micro-Services can be thought as Object-Oriented for cloud (or distributed application).
the most granular unit of Micro-Services called Actor.
Actor is similar to class in the Object Oriented paradigm.
group of Actor can be packed (and deployed) just like classes can be packed within assembly (Component Oriented).
Actor can send messages to other Actors like classes can invoke methods on other classes.
Service Fabric offer a few programming models
– reliable services model (which is kind of advance web/worker role)
– reactive extension (RX) model (which is very powerful pub/sub api)
– actor-based model which I will discuss further on this post
What problems does it try to solve?
Service Fabric aim to simplify coding of distributed enterprise code
and take care of aspects like Optimal utilization of resources, Scalability, High Availability, Data Integrity, etc..
why enterprise code is getting complex?
when moving from Object Oriented (or Component Oriented) toward distributed application
you need to address lot of non-functional consideration like: Scalability, High Availability, Data Integrity, etc..
this make our solution way too complex than we desire.
addressing non-functional aspects, often come with price of adding components like cache and queues
which get the overall solution more complex
Service Fabric meant to take care of most of the non-functional requirements and
keep the actual functionality relative simple.
Service Fabric handle the following
* Deployment (Balancing actor across the cluster)
* Upgrade (update new version with no down-time)
* Resiliency detect and rebalance actor upon failures
Distributed .NET + IoC
Service Fabric manage the life-time of Actors, It can deactivate Actor just like the .NET can collect instance of a class.
Actors consider virtual (which is kind of lazy instantiation), means that the Service Fabric control its activation.
Service Fabric may balance the cluster nodes by deactivating Actor on one node and activate it on other node.
the API reminds IoC. you have to register the actor (of each deployment unit)
and just like IoC’s resolve, you ask for Actor’s proxy when you need to operate against it.
the actual instantiation of the Actor managed by the Service Fabric,
which create single stateful instance per Actor Id (stateless actor may have more than single instance per Actor Id).
this is why Service Fabric can be thought as distributed managed IoC (or IoC of the cloud).
Actor is single threaded entity (similar to Node.js) and synchronize in a turn base concurrency.
which mean that actor is having inherent reliable queue and it process the queued message by message.
Actor dequeue the next message when it complete the previous call.
this why you don’t have to deal with synchronization within the actor scope.
see more on this topic in here.
Service Fabric is powerful framework for distributed application that take care of many non-functional concerns
and offer powerful model of Actor-based programming.
it’s also offering service-base programing which is very close to the previous Worker or Web Role model
that come with stateful model and better deployment and resource management.
and Reactive Extension (Rx) model for advance Pub / Sub scenarios (this topic will be cover in details on future posts)
next on this series I will discuss guidelines and common pattern mainly targeting the Actor and RX models.