In this post, I’ll example Service Fabric, a microservices deployment compute-based system in Azure.
This post is aimed at IT pros and you might wonder why you’ll care about some system in Azure’s Platform-as-a-Service (PaaS). Service Fabric is one of the many resource types in Azure that is a bit of a cross-over technology, using compute as a platform and therefore requires networking, security, and more. Whether you work in DevOps or not, if developers in your company plan on using Service Fabric, then you’ll be involved in the deployment and maintenance of the underlying infrastructure.
What Is Service Fabric?
Service Fabric is a solution that layers and orchestrates microservices on top of a compute cluster. That compute cluster is a scale set of Azure virtual machines; this means that you can create a relatively small deployment and scale it out and in automatically, depending on application demand.
Developers using Service Fabric to run their application use a different approach to writing their code. Instead of creating one big executable or DLL, they write smaller chunks of code that are uploaded and run separately as microservices (called agents) in the service fabric cluster.
Each microservice instance is replicated across the scale set and that replication is extended as the scale set grows. This offers two things:
- High availability
- Performance via scale-out
When a programmer is creating a new service for Service Fabric in Visual Studio, they have a variety of options but they boil down to two categories:
- Stateless services: Some piece of code that takes an input does something and immediately passes it on.
- Stateful service: A piece of code that temporarily stores data on a local (scale set node) disk and works on it there.
Without stateful services, every piece of data would have to be written to some form of Azure storage, such as a storage account or database and that would increase latency. By using local storage, the service’s performance is increased.
I recently attended an Azure architecture boot camp run by Microsoft and that is where I first learned about and deployed Service Fabric. The solution was a ticket sales one where a simple website was powered by a backend API. This API was an Azure API Management resource that shared the functionality of the Service Fabric microservices (Swagger). I was struck by how elegant the concept was:
- The application code is shared to external systems (web apps, mobile apps, partners) via an API interface.
- Performance is easily achieved by scaling out the scale-set.
- Programmers can quickly and easily introduce code improvements by updating a single microservice.
- Upgrades to the microservices are done directly from code management (such as Visual Studio) and are orchestrated by Service Fabric – a failure automatically rolls back to the previous version of the microservice.
- There’s a nice dashboard to monitor/manage the Service Fabric instance and its hosted applications and microservices.
IT Pro Involvement
You’ll probably have little-to-no involvement in the operations of Service Fabric. This is a set of virtual machines that live on a network that will have some kind of external/internal connectivity and security/governance requirements. That’s where you come in and that’s why you should know about Service Fabric.