This post is part of a Service Fabric series
- Introduction to Service Fabric
- Creating a WCF Service for Azure Service Fabric
In the beginning (not so far away) it was the local server, and developer’s life was a chaos. IT team (if existing, otherwise the developer itself) was responsible of ensuring the server where the applications was installed worked as needed. It was his fault if this didn’t happen.
Later, whit the use of virtualization the cloud came bringing the ability of give us the chance of blaming transfer the responsibility to someone else.
What does all this have to do with this post? Microsoft Azure Service Fabric is a Platform as a Service option, built from scratch for supporting cloud, distributed, high-scale and high-availability applications. It started as a proposal for cloud databases (CloudDB) and currently is being used on rockstar Microsoft Products like Cortana, Skype for Business, Power BI, SQL Azure, etc.
Its main advantages are in the easiness given to developers for managing elements that are beyond functionality, like
- Rolling updates
- Logging
- Monitoring and telemetry from the services
- Failures
- Security
This way developer can focus all his efforts and attention in coding.
Microservices
Even though it is normally associated with microservices, Service Fabric benefits can be useful in multi-layer applications, APIs, etc. But, what are microservices? Although there is no standard definition, they are normally identified by spliting application functions in small parts. These parts are independently versioned, written in any language or technology and oriented to solve a concrete situation from the problem is intending to tackle. It is important to be clear that monolithic is not bad neither microservices is good; it all depends of the scenario and context.
By being distributed independently in different nodes (containers, servers, virtual machines) within a cluster where the replication and partition process is performed, each microservice can be scaled according to its own needs.
Cluster
Service Fabric can run the same on Microsoft Azure, other clouds providers like AWS and even on private clouds, no matter if it is Linux or Windows. Even at development time, the required components are exactly the same, what makes really easy to move from one environment to the other when it is needed. This is because the components where thought to be standard and is not needed to make modifications according to the environment where it will be executed.
The cluster is a set of nodes components installed and configured to communicate each other; it provides an abstraction level between the application and the infraestructure where it’s executed. The main cluster abilites are
- Supporting thousand of nodes
- Dynamic change
- Isolation unit
Infrastructure Services
Service fabric provides a set of services to help with infrastructure management
Cluster manager
In charge of cluster operations. By default it can be managed using REST through port 19800 with HTTP and with TCP through port 19000 using Powershell.
Failover manager
In charge of detecting when new nodes are added to the cluster, when they are removed, or when a fail occurs in order to re-balance for high availabiliy.
Naming
Maps the services with the endpoints, so the can communicate each other.
Fault Analysis
Helps you to introduce failures to your services so you can test different scenarios in a controlled manner.
Image Store
Contains the actual bits of the services, the master used for creating the copies that are replicated on the nodes.
Upgrade
In charge of updating Service Fabric components, exclusively on Azure.
Programming models
When working with Service Fabric, you have 3 options for creating your services
Reliable services
Provides a simple way for integrate with Service Fabric when creating your services, benefiting from the platform tools.
Reliable actors
Built on top of Reliable Services capabilities, it’s a framework that works with single-threaded units called Actors, based on the design pattern with the same name.
Guest executable
It’s just that, an executable that you can deploy to service fabric cluster, without fully integrating with the platform; Service Fabric just ensures the exec stays up and running. The programming language doesn’t matter, so it is a good option for existing applications.
Application and services
An applications is basically a set of services, defined in ApplicationManifest.xml file; in Service Fabric terms, we name it Application Type. Based on this type we create an Application Instance, that is the one we hit at runtime; this is very similar to the class and instance concepts in OOP. The same goes for Service Type and Service instance; additionaly it’s composed by 3 parts: code, data and configuration.
Each of this elements has its own version, so we can have an Application with version label 2.1.1 composed by one service with version 1.0.0.
That’s it for now; we’ve covered Service Fabric concepts that will be used for our next tutorials.