Decrypting Service Fabric Architecture
This week I have been focused on Service Fabric. One of the teams that I work with is trying to find out more about the product as they try and decide if it’s time to start breaking up monoliths.
One of the challenges that I faced when trying to first understand Service Fabric is what exactly it is. When you read our documentation it seems to start talking about the service as if it’s a PaaS platform but then immediately starts jumping in to C# examples of how to construct things. We seem to have muddied the water a little bit as to what the platform actually does.
To help with this I put the chart below together:
The basics of Service fabric architecture lays out into 3 layers:
- Infrastructure
- Scheduling/Orchestration
- Workload
I’ll go through and give a brief overview of each segment below.
Infrastructure
Within Azure the Infrastructure layer for Service Fabric is provided by VM Scale Sets. VM Scale sets were introduced to the platform in 2016 and manage the orchestration of elastic scaling VMs. You can configure autoscaling on a VM Scale set using either built in, or custom metrics. This allows your Service Fabric cluster to grow and shrink to keep up with system demands. Service Fabric currently supports running on Windows scale sets, but has a preview option for Linux scale sets.
Service Fabric is not an Azure only product. It can be run on premises as well. This probably contrasts it with the Azure first offering like App Services. While not clearly advertised the system requirements could easily run on other clouds as well. Service Fabric could easily become part of your multi-cloud strategy if that is one of your system goals.
Scheduling/Orchestration
Before I start diving in to this layer, a word of warning. Service Fabric is often referred to as one product, when in reality it’s at least two. When you read the documentation it refers to the two products interchangeably as the same thing, in order to be as confusing as possible. The first of the two products is the orchestration component discussed here, the second is the Java and C# framework discussed in workload section.
Service Fabric’s orchestration layer manages the availability of the microservices within the fabric. Someone mentioned to me yesterday that the platform is very reminiscent of containers. While that isn’t the whole story the orchestrator would align closely to Swarm, or Kubernetes for containers. The orchestration layer provides the following services:
- Service location — A URL based mechanism for services to locate and communicate with each other.
- Workload Scheduling — Service Fabric provides initial workload placement, as well as re-placement in the event of a node failure.
- Health Monitoring — Metrics are exposed on both the overall health of the cluster, as well as the health of applications within the cluster
- Application Upgrade Orchestration — The system provides rolling upgrade orchestration so that an application can gracefully be upgraded, as well as fault detection supporting automatic fallback in the event of failure
- Application Manifest System — The system provides a robust manifest language allowing you to define to the fabric many settings regarding scale, placement, and configuration of your application within the cluster.
Service Fabric provides the features that you would expect out of a product of this type. Service Fabric’s history helps it’s maturity here. While the product hasn’t been on the market very long it has been used inside of Microsoft as the application standard for developing several of Azure’s largest services, as well as Azure itself.
Workload
Service Fabric can support the following workloads:
- Containers — Added as a preview feature in 2016 Service Fabric can support container based workloads, specifically on the Linux variant today.
- Custom EXE — You can easily repackage an EXE with a manifest to be deployed to the cluster. Anything you want to run, just set it free in the fabric.
- Service Fabric Framework — A lot more on this below, this is the second of the two products referred to as Service Fabric. There is full GA support for Java, .Net, and preview support for .Net Core today.
The service fabric development framework (Reliable Service Framework)is what in my mind sets itself apart from other similar products . It’s an opinionated framework that allows for the rapid development and deployment of MicroServices. This is a complex and rich framework that does take a little getting used to, but yields great results. The 3 key types of services that you can develop are:
- Stateless Reliable Service
- Stateful Reliable Service
- Reliable Actor
A stateless service is a lot like everything you’re likely developing today. No state is stored in the service itself. You can provide external communication through REST, WCF, or pure RPC. You would hold state for a service like this outside of Service Fabric in a database just like you do with a traditional web service. Visual Studio 2017(and possibly earlier versions) provides an out of the box template for REST API’s that feels very much like a traditional .Net 4.x API app.
Stateful services are likely to be different than what you’ve been developing today. They allow for state to be stored directly in your application. It does this by storing, and replicating the state between the nodes themselves. It then exposes this up to the developer as 2 new types. A reliable dictionary, and a reliable queue. Objects that you store into these reliable collections can be accessed across application instances, across nodes, and even in the event of service restart. This allows you to cache data close to your execution and allow you to do things that aren’t possible in a purely stateless service.
If stateful services are different from what you do today reliable actors are even more different. They’re built around the actor model, which apparently has existed since 1973. Actors function as independent state and logic. I struggle to provide an easy analogy for them. The closest I can come up with is to imagine an object that is responsible for its own lifecycle and can execute it’s methods independent from outside execution. It may be easier to see their purpose through use case. We all have areas in our code base where we iterate on something on a recurring basis, check it’s state and then take action based on state. An actor provides an alternative to this. In an actor model I would take each of those records an wrap an actor around them(that’s the state), and then build the actor so that it evaluates itself regularly and takes action accordingly. Since each actor is an independent thread you end up making a process massively parallel. Actors allow us to solve some problems in a more elegant way than other programming models.
A final word of caution on actors, they initially look very intriguing, however they come with some challenges. They are single threaded only. Make sure to think through your architecture carefully before using them. More on that next week.
I tried to explain the 3 layers within the service fabric architecture, Infrastructure, Orchestration, and Workload at a high level. Hopefully through that process it gives you a clearer vision of where it fits. It provides a road tested platform for deploying Microservices that provides some unique capabilities that others don’t provide. Whether you’re ready for Microservices can’t be answered by a platform.
