An Introduction to Azure Service Fabric
Azure Service Fabric is Microsoft’s offering of a service framework that helps you build and manage your microservices applications — either upon cloud technologies or on your own on- premise infrastructure.
(This article was originally posted on Mitra Innovation’s official website)
Given the attention received in the industry, the term ‘microservices applications’ shouldn’t be an unfamiliar one to the reader. Microservice concepts and its surrounding ecosystem experienced a boom during the last few years. And, there we saw a lot of contributions from individuals and organizations propelling the growth of advancements in the field of microservices technologies.
Azure Service Fabric is Microsoft’s offering of a service framework that helps you build and manage your microservices applications — either upon cloud technologies or on your own on- premise infrastructure.
In this article, we are going to focus on understanding what service fabric means, its underlying concepts, how it works and the benefits of using service fabric.
A quick intro to Microservices
Before further diving in to Azure Service Fabric, it is necessary to understand what a microservice is and why it matters.
Martin Fowler, in his website, explains — “The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms; often an HTTP resource API. These services are built around business capabilities and are independently deployable by fully automated deployment machinery.” –
In brief, microservices are an architectural method of developing software applications as a suite of independently deployable, and — relatively small — modular services.
In contrast to the traditional ‘monolithic’ approach of building and deploying all the business logic and different application layers together, each of these ‘microservices’ focus on a unique business problem and are independent from the rest of the services in the application.
Additionally, a particular microservice runs on its own process and it can be deployed, updated or scaled without affecting the rest of the services in the application.
For the moment, let’s not focus on the architectural or software development benefits of microservices; instead let’s have a quick glance at the edge it provides on infrastructure point-of-view. Because this is where Azure Service Fabric is trying to capitalise.
In a traditional monolithic application, all components (relating to business logic and API) are deployed and managed as a single unit. This could introduce few complexities such as; a small change in a single component might mean you have to redeploy the entire application. Or even, a high load on a single API method will result in scaling up the entire application infrastructure and therefore incurring a larger cost.
Fortunately, with microservices this isn’t the case. Because they are individual modular services, changes to a single microservice can be deployed with minimal impact to the rest of the application. Also, individual services can be scaled up or down based on demand without impacting the rest of the services.
What is ‘Service Fabric’?
The intent of Azure Service Fabric is to provide a distributed systems platform that allows developers to build and deploy microservice applications without enduring typical complexities and problems usually associated with microservices application development.
For example, with service fabric, developers will not have to lose sleep about infrastructure problems such as scalability, reliability, failover and telemetry. It also significantly reduces the burden on application lifecycle management — by introducing workflows for provisioning, deploying, patching, and monitoring services.
If we take a look further beyond the above abstract definition of Service Fabric — the main concept behind it will be the “Service Fabric Cluster”. Technically, a service fabric cluster is a collection of servers — either physical or virtual or a mix of them — (which are most often referred to as “nodes”) that are stitched together via a special piece of software.
And this piece of software — Service Fabric Software — is responsible for keeping track of individual nodes and ensuring the resiliency of applications deployed in to the cluster.
Why ‘Service Fabric’?
Like mentioned earlier, Azure service fabric bears several key characteristics to support microservice application lifecycle management, scaling, availability, upgrades and resource efficiency.
Let’s take a further look in detail.
Rolling upgrades — Microservices can be published on different machines/nodes, and on different platforms using Service Fabric. Therefore it’s essential that all copies of application services are properly upgraded during a deployment. Azure Service Fabric automatically does this for you by upgrading applications at zero down time; taking down one node at a time and diverting traffic accordingly.
Guaranteed availability — With Service Fabric, the burden of handling fail-overs are taken away from you by introducing self-repairing, scaling in/scaling out nodes. When a particular node is not available, the Service Fabric cluster automatically pops up a new node including the relevant application (services) and routes traffic to it.
Independent scaling — As mentioned previously, one of the key drivers of microservices architecture is to be able to scale independent services. Azure Service Fabric can automatically control the scaling of a particular service by populating or removing a number of nodes that run the same service.
Resource Efficiency/resource governance — Service Fabric allows you to better balance your application. Your application might have any number of services. Service Fabric allows you to have more instances of the same high resource consuming services, which will use most of the resources where necessary. And also, possibly group low resource consuming services if needed.
Policy enforcement — We can control how an application behaves on service fabric. For example, we can tell service fabric that a particular service should not use more than a certain amount of memory, or certain amount of CPU resources…etc. (Also, Service Fabric has rich monitoring facilities which allows you to keep a close pulse on the applications and the underlying nodes).
Stateful/stateless application workloads — Some of the services in your microservice application may be state aware while others are not. Service fabric supports both stateless and Stateful services running within your cluster.
Supports multiple platforms — Service fabric can be installed in any public cloud. Even though it provides first class support for Service Fabric, it doesn’t’ necessarily have to be Azure cloud. Be it Amazon or any public cloud which has Windows or Linux machines — Service fabric can be installed and run.
Not only limiting to cloud infrastructure, Service Fabric can also be installed upon any on-premise infrastructure.
For developers, there’s a Service Fabric SDK available. This SDK will effectively install the same set of components in to the developer machine. Usually these development environments are referred to as ‘OneBox’ because unlike a service fabric cluster where multiple machines are connected, Dev environment has all the nodes inside the same machine.
Supports multiples languages/frameworks — It doesn’t necessarily have to be a Microsoft .Net technology. Service fabric can host a wide variety of applications that are developed on (but not limited to) Java, Spring Boot, Node… etc.
Service Fabric is free! — Another important thing to mention is that Service Fabric is totally free. There are no costs attached to the service fabric components itself. You will only have to bear the cost of the infrastructure that Service Fabric is running. For example, if you’re running service fabric on Azure cloud, you’ll get billed only for the virtual machine hours that service fabric is using.
Service Fabric Cluster
Let’s have a quick look in to how Service fabric really works. The following diagram shows an Azure Service Fabric cluster in a data center. This data center can be Azure, Amazon or may be your on premise server — it doesn’t really matter.
First thing to note is that there are a few machines (PCs/Virtual Machines) inside the datacenter — which are called ‘nodes’. Though this diagram only shows a few; a service fabric cluster can actually support thousands of nodes. These machines need to have either Windows or Linux operating system running on them.
Each of these nodes have an installation of Service Fabric software. But that’s not enough — service fabric components in each node needs to be able to communicate to each other. This can be done by installing a component called ‘Cluster Manifest’ in to each of these nodes.
Cluster manifest is essentially a dynamic configuration file which contains information about other nodes in the cluster (e.g. IP addresses of other nodes). Let’s emphasize that these nodes can be added or removed from a cluster dynamically.
Once a ‘cluster manifest’ wires up all the nodes together, it eventually becomes a ‘Service Fabric Cluster’.
In a typical deployment, we usually have a load balancer in-front, but note that this load balancer doesn’t come with Service Fabric. So it has to be either from the cloud platform itself or any other third party load balancer you prefer to have.
Service Fabric’s infrastructure components
Other than the aforementioned Cluster Manifest, there are several other components that run on each individual service fabric node. Most of them are system infrastructure services that supports various aspects of Service fabric platform.
In addition to the above there is another service that is available only within Azure environments. It is known as an upgrade service — which is responsible for upgrading various components that are installed in service fabric nodes when there are newer versions of those components provided by Microsoft.
Service Fabric nodes
One important thing to note is that it’s not necessary for nodes to have a one-to-one mapping to the underlying PC or VM. One machine can technically have more than one service fabric node running inside it, though it’s not a commonly followed pattern in production environments.
Following diagram shows the main internal components of a service fabric node.
- FabricHost.exe — Core service that hosts the service fabric components and other relevant services required by the node
- Fabric.exe — A component that is responsible for inter-node communications
- FabricGateway.exe — This component is responsible for internal communications inside the cluster.
Along with the above mentioned fabric.exe and fabricgateway.exe, your application artifacts forms the components of a service fabric node.
Service Fabric application concepts
Even though the constant use of the ‘service’ terminology might imply that all service fabric applications need to be web services (or at least web applications) it isn’t necessarily the case. Some of the service fabric application components can actually be a console application that processes some input or performs a particular action. A service is literally just a process that you would want to run.
A service fabric application can be broken down into three major parts; code, config, and data. And, it is not mandatory that a particular services need to have all three components; for example there can be a service that doesn’t work on data.
A particular application component (or a ‘service’) acts as a containerised, functional unit. It can be developed and revised individually, and can also start/run independently. Further, these components are versioned so that it is easy to identify the functionalities of each individual service that is running.
When all these services (or in other words application components) come together they form a high-level business application that is more scalable and easier to manage.
Real-life examples of Service Fabric usage
Originally Microsoft started working on a platform which can provide solutions to most cloud based application problems (like custom scaling, application fail-over, rolling upgrades, rich telemetry…etc.) while they were building up the SQL Database services on Azure.
Later, they realised that most of the behaviors would be reusable in other applications and therefore generalised that platform which has eventually grown in to Azure Service fabric.
Today, while there are thousands of customer applications which run on Service Fabric, a number of Microsoft’s own products and services utilise the platform itself.
The following are few examples out of those products;
- Skype for Business
- Power BI
- Cortana
- Azure Core Infrastructure
- Azure Document DB
- Dynamics 365
- Intune
- Azure Event Hubs
Conclusion
So far, we managed to scratch the surface of microservices architecture and how Azure Service Fabric comes in to the picture to support better development and deployment of microservices applications. We also understood how Service Fabric works and some of its core components and inner workings.
In another article we will examine how we can build and deploy a simple microservices application on Azure Service Fabric.
