This is Preview 1 of Azure Service Fabric. If you aren’t sure what that is, look on the left. Onebox is my laptop, and it is running a local cluster comprised of four applications and five nodes. The applications are named ClusterManagerService, FailoverManagerService, ImageStoreService and NamingService. Sound familiar?
Those four applications are what we commonly refer to as “Azure.” That’s the Azure Microsoft runs in the cloud to host Azure SQL Database, Power BI, Cortana, DocumentDb, Event Hubs, and “many other core Azure services”. That Azure is now running on my laptop.
Which means I can build Azure apps and run them locally on real Azure, not an emulator. I’ll be able to deploy them to Azure on Microsoft’s public cloud, and they’ll run the same there as they do locally. And I’ll be able to deploy them to on-premise data centers or ISV data centers when they run Microsoft Azure Stack on Windows Server 2016.
I haven’t gotten a chance to try a HoloLens yet. But this is plenty of excitement for me. Let’s consider how Azure Service Fabric apps are different from other apps.
Azure Service Fabric applications run in clusters. A cluster is a group of virtual or physical machines, each hosting a collection of isolated processes called nodes. On my laptop a Windows Service called FabricHost.exe is managing the cluster. Each of the five nodes is implemented by a trio of Windows processes running Fabric.exe, FabricGateway.exe and FileStoreService.exe.
An Azure Service Fabric application consists of one or more microservices. Each microservice will be deployed in one or more containers on one or more nodes. Microservices run in isolation from each other, and can be either stateless or stateful.
Here is what my Service Fabric Explorer looks like after I have deployed four Service Fabric applications (one from each project template in Visual Studio). Each application contains one microservice, but most of them are deployed on multiple nodes.
What can we gain by dividing applications into microservices and running them on clusters of nodes?
First we gain High Availability. When a microservice crashes, the Service Fabric intervenes immediately to redirect traffic to a backup copy of the microservice on a different node. Thanks to the Naming Service, microservices hide their physical locations, so redirection to a new instance happens transparently. Service Fabric then instantiates a new microservice instance to replace the old one. If the failed microservice is stateful, then the backup instance will include its own copy of the state, and the replacement instance will get a copy of the current state as well. By the same means, Service Fabric can quickly recover from the loss of an entire node or the loss of an entire machine in the cluster.
We gain High Scalability. We can have as many instances of our microservices running on as many nodes as we need. We can constantly right-size our deployment to optimize performance while minimizing costs.
The support for stateful microservices brings important advantages, and I think this is one of the big things that sets Service Fabric applications apart from other kinds of Azure applications. By putting state side-by-side with code – by not separating between “service tiers” and “data tiers” – we can dramatically Reduce Latency. Think of Microsoft’s Cortana, an Azure service that finds restaurants and looks up movie times in split seconds. And by packing data and computing together, we can reduce our apps’ hardware footprint and thus further Reduce Costs. And the Programming Experience for developers can become much simpler.
The last big gain I’ll mention now (I’ll talk about many more in coming posts) is support for Rolling Live Upgrades. To deploy a new version of a microservice, you don’t need to stop what’s already in production. Service Fabric will create instances of the new version and silently substitute them for old instances as they become idle, taking care that work underway is never handled by inconsistent versions. This is the same way Microsoft rolls out updates to Azure SQL Database and its other cloud services.
I think these make Azure Service Fabric an excellent platform for building all sorts of apps, but especially mission critical apps, such as
- Apps that need to run all the time, never going down for planned or unplanned reasons
- Apps that handle heavy workloads
- Apps requiring split-second throughput
- Apps with heavy resource demands that need to be frugal with costs
In this series I will explore Azure Service Fabric in some detail. Watch for more posts exploring the architecture, the tooling, and the application lifecycle on this new but proven platform.
In the meantime you can start your own exploration by downloading the Service Fabric Preview 1 here.