In this post, I’ll example Service Fabric, a microservices deployment compute-based system in Azure.

Relevance

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

Service Types

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.

: 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.

Scenarios

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.

Subscribe to Petri Newsletters Office 365 Insider Our Petri Office 365 Insider is dedicated to sharing detailed knowledge from top Office 365 experts. Delivered once a month to your inbox. All Newsletters Petri.com may use your contact information to provide updates, offers and resources that may be of interest to you. You can unsubscribe at any time. To learn more about how we manage your data, you can read our Privacy Policy and Terms of Service. !Already a Petri.com member? Login here for 1-click registration.

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.