Review: Microsoft masters microservices

Many businesses either have implemented or claim to be implementing microservice architectures, for better or for worse. Microservice architectures give you strong module boundaries, independent deployment and independent scaling of lightweight pieces, isolation of concerns, and the opportunity to use whatever technology is appropriate for each small service. On the other hand, distributed systems inherently have higher latency and more opportunities for failure than monolithic systems, as well as higher operational complexity, so the application has to be “big enough” to justify the overhead of being distributed.

Let’s assume you have an application that justifies the overhead of being distributed, and you want to implement it as a set of microservices. The next questions to ask are where and how you should deploy and maintain your microservices.

Microsoft’s answer to these two questions:

• On Azure Service Fabric
• However you want

As you’ll see, Azure Service Fabric offers many benefits, at the cost of some complexity.

Middleware for microservices

Azure Service Fabric is middleware designed to help you build and manage scalable and reliable microservice applications running at very high density on a shared pool of physical or virtual machines (that is, a cluster). For production purposes, each node of a cluster resides on a separate machine. For development and test purposes, many nodes can reside on a single machine.

According to Microsoft, by using Service Fabric, developers and administrators can avoid having to solve complex infrastructure problems and focus instead on implementing demanding, mission-critical workloads with the knowledge that they are scalable, reliable, manageable, and testable. Service Fabric hosts microservices inside containers that are deployed and activated across the cluster. A single Azure SQL Database cluster, built on Service Fabric, is composed of hundreds of machines running tens of thousands of containers hosting a total of hundreds of thousands of databases. Microsoft calls this “hyperscale.”

Whether Azure Service Fabric will actually help you may depend on two factors: whether your application can easily be decomposed into microservices, and whether those microservices can be expressed in a form supported by Azure Service Fabric. Fortunately there is more flexibility in Service Fabric scenarios than I initially expected. As you’ll see, while Microsoft emphasizes Azure, the .Net stack, and Windows Server hosts, it allows for alternatives to all of the above.

Service Fabric scenarios

Service Fabric scenarios include stateful and stateless microservices, reliable actor and reliable service apps, and guest executables. All but the guest executables are .Net apps that call the Service Fabric APIs.

Reliable service apps, which are long-running services that typically have listeners and multiple replicas, can be stateful or stateless. In a stateless service app, there is no stored state, so the app is pretty much a handler for incoming requests, similar to a website without cookies, except that service apps are not restricted to HTTP protocols -- you can call them with an API over a variety of pluggable protocols. In some architectures, a stateless service app acts as a front end to a stateful service, like a Web front end to a business logic layer.

It’s possible to have a partially stateful app that keeps some state in an external database, for example, but doesn’t use stateful Service Fabric APIs. On the other hand, a fully stateful reliable service app can store its state internally with the Reliable Queue and Reliable Dictionary APIs. Reliable Queues and Reliable Dictionaries are kinds of Reliable Collections, which are provided by Service Fabric and, hence, are highly, umm, reliable, as well as available and consistent. Storing your state internally has clear performance advantages: Every read and write is local, not a request to a remote database.

If you need a stateless service called only by HTTP requests, you can create a stateless Web API. This is basically an ASP.Net Web API with OWIN self-hosting, running in a service host process, hooked up to an OWIN host such as Project Katana rather than running on an instance of IIS.

Reliable actor applications

The virtual actor pattern was developed at Microsoft Research in Project Orleans and field-tested by implementing the back-end services for Halo. Reliable actor apps are a publicly available implementation of the virtual actor pattern. Basically, an actor is an isolated, independent unit of computation and state with single-threaded execution. The actor pattern is a computational model for concurrent or distributed systems in which a large number of these compute units can execute simultaneously and independently of one another. Actors can communicate with other actors, and they can create more actors. If that reminds you of Erlang, you have the right idea. Virtual actors are a generalization of the actor ideas embodied in Erlang.

The reliable actor implementation in Service Fabric is actually a specialization of stateful reliable services, with an implementation of partitioning thrown in to distribute the load to the actors and provide for automatic failover. Actors have turn-based concurrency. Even though actor APIs are asynchronous, an actor can process only one request at a time; this is enforced by a per-actor lock held for the duration of the turn. While “turn” is most meaningful in the context of a game, you can think of it as the full response to a single request.

When would you use reliable actors, other than for a game? The following are the three major criteria suggested by Microsoft:

• Your problem space involves a large number (thousands or more) of small, independent, and isolated units of state and logic.
• You want to work with single-threaded objects that do not require significant interaction from external components, including querying state across a set of actors.
• Your actor instances won’t block callers with unpredictable delays by issuing I/O operations.

Based on these criteria and the body of experience with Erlang, one obvious application would be for telecom. Other possible applications might include finite element simulations, global optimization problems, molecular dynamics simulations, genetic modeling, and constrained partial differential equation solvers such as fluid dynamics and heat transfer simulations. Will actor-based implementations of those applications turn out to be simpler, better, faster, or more maintainable than traditional implementations? It’s hard to say.

Service Fabric architecture

The Service Fabric architecture involves nine subsystems, providing such functionality as a point-to-point datagram communication channel, federation services, replication, failover, resource management, cluster management, health management, an image store, a hosting interface, naming, reliable communications, and testability.

Most of that functionality is obvious from the names. Testability gives you easy ways to simulate hardware and software failures, either with single actions such as restarting a node or complex scenarios such as “failover” (generate faults on a specific service partition) and “chaos” (generate faults across the entire Service Fabric cluster, and let all hell break loose).

“OK,” you say, “I love the whole idea of running an app on Service Fabric, but I have an existing app I want to scale out without doing the work of rewriting it as a service. Can Service Fabric help?”

As a matter of fact, it can. Service Fabric can run guest executables once you write (or use a tool to generate) application and service manifest files that specify the code and configuration file names and the entry and end points for the service. Basically, any application that can run on the underlying host (usually but not always Windows) can run as a guest executable. Service Fabric will then treat it as a stateless service, providing high availability, health monitoring, application lifecycle management, and high application density.

In the last paragraph I mentioned that Service Fabric hosts are usually but not always Windows. For a development and test configuration, you can use Windows 7, Windows 8/8.1, Windows Server 2012 R2, or Windows 10, plus Visual Studio, the Service Fabric runtime, and the Service Fabric SDK. For production, you can use Azure, Windows Server 2012 R2, Windows Server 2016, or Linux, specifically Ubuntu Server 15.10 in the current limited preview. The Windows and Linux instances can run on physical servers, VMs, or any cloud. Service Fabric is well-supported on Azure, but not locked into Azure.

Building and deploying Service Fabric apps

You can build, deploy, and manage Service Fabric apps a number of ways, using a variety of tools: Visual Studio, the Azure console, PowerShell, the Service Fabric Explorer, and Visual Studio Team Services. With Team Services, you can set up an automated continuous integration process.

I set up two development environments on Windows 10 machines, one using Visual Studio 2015 Update 2 and one using the Visual Studio “15” Preview. The former was an upgrade of an existing installation; the latter was a clean install on an instance that hadn't seen Visual Studio before.

You’d think the upgrade would have gone faster, but you’d be wrong. After five failed tries to fix Visual Studio 2015, I gave up and reinstalled Windows 10 from bare bits, as well as a freshly downloaded Visual Studio 2015 with Update 2 and finally the Service Fabric SDK and runtime. Elapsed time: more than 24 hours. My opinion of the Visual Studio update process: Shoot me.

Once everything was installed, actually creating a Service Fabric app was fairly tame. Deploying the app on a local cluster was more “interesting” because firing up a five-node cluster on a modest development box with 8GB of RAM involved quite a bit of clanking machinery, reminiscent of the days when I got to work, started Visual Studio 2010, boiled water, brewed tea, and brought my mug to my desk as my ongoing C++ development project finished loading. Note that creating a cluster is noticeably faster on SSDs than hard disks.

If you have a development machine with enough RAM and CPU resources, you can leave your local Service Fabric running all the time. I didn’t have that luxury, so I had to shut down the cluster to do other tasks on that development box. When I next needed to deploy my app, it was again time to boil water and brew tea.

Cluster management and app scaling are all fairly straightforward on the local machine. It shouldn’t be much more complicated on Azure, but alas it was seriously complicated. Configuring a cluster from scratch on Azure using the Azure console involved a long laundry lists of choices and configuration steps. The Azure setup needs to be better automated -- nor is running an Azure Service Fabric cluster of any worthwhile capacity especially cheap. You need a minimum of five VMs for a legitimate production cluster, so multiply the monthly VM cost in the figure below by at least five.

Azure Service Fabric, while “just middleware,” is more than meets the eye. It can give your microservice-based application the sort of reliability, manageability, and scalability that once required a full-blown PaaS. Although Service Fabric still needs work in portability and ease of installation, its benefits for applications with massive numbers of users are significant.