If there’s one thing the cloud is good at, it’s hosting and running highly scalable applications. Unfortunately, by itself, the cloud doesn’t make building applications that can scale rapidly any easier. Distributed systems need to handle such complex issues as concurrency and consistency, which require new design patterns and new ways of working.
Technologies like Node.js are ideal for building microservices-based applications. But even if you employ tools like MQTT and Seneca, you still need to build your own management tooling to handle scaling. Yes, you can take advantage of AWS Lambda to work with Amazon’s PaaS-hosted Node.js to run at scale with external triggers driving applications, but that’s not the general-purpose cloud platform developers seek.
Microsoft’s next-generation PaaS
Enter Microsoft’s recently announced Azure Service Fabric, a complete reworking of Azure’s original PaaS for the modern cloud, with a focus on composing cloud-scale applications from clusters of microservices. Because Service Fabric is a PaaS, there’s no need to worry about servers or containers: The underlying high-density infrastructure is handled by Azure. It’s also a proven platform that today runs many core Microsoft services, including Cortana and Azure’s various database platforms.
While the original Azure PaaS was stateless, making it hard for developers coming from a traditional application development background to get comfortable, Service Fabric offers both stateful and stateless options. Both approaches have their benefits in the cloud. Maintaining state can be important in fault-tolerant systems, and the fact that this capability is built into Service Fabric means you don’t need to add extra layers to an application and increase latency.
One aspect of microservices that Azure Service Fabric brings to the fore is the mapping of microservices to user “stories.” In Service Fabric, a microservice can be a shopping cart, a user profile, or any other specific element of an application that needs to scale. Making a microservice user-centric puts a cognitive wrapper around it, so it’s easier to understand and implement. Scaling becomes a matter of scaling with the number of users and firing up services to match interactions.
Service Fabric under the hood
Let’s take a closer look at the application model Service Fabric uses. Like most modern application platforms, it’s designed to compose and orchestrate services, where services are a combination of code, configuration data, and the data a service operates on. The application bundles services, with each application operating in a separate process -- even if you have several instances of an application running at the same time.
This arrangement lets you manage application lifecycles more effectively, upgrading separate instances without taking down an entire application. Similarly, you can run multiple instances of a service in an application, with services distributed across the nodes of a cluster to improve reliability and availability.
Services can be partitioned, with each partition managing state separately, giving you the option of scaling by delivering load to specific partitions using unique keys from your data set. For example, you can use a hash based on insurance policy numbers to distribute load across a partitioned claim management service.
Services are described using an XML manifest, which tallies the code, configuration, and data packages used in the application, as well as the initial entry point for the service -- usually a pointer to the service host and the process that’s launched if that service ends abnormally (typically a service restart).
Each application has its own manifest, allowing you to define the services used and the versions needed. Manifests also describe the package structure, which handles how application binaries are deployed in Service Fabric clusters.
New design patterns
One of the issues with building scalable distributed applications is that the many of the design patterns we’ve used in n-tier application development break down. To help get around this, Azure Service Fabric offers two different development frameworks to handle different application types: Reliable Actors and Reliable Services.
The two offer different ways of working, but you can mix and match. For example, you can build a stateful service that manages feeds from stateless actors using a Reliable Service to manage Reliable Actors.
For many hyperscale scenarios -- especially when working with the Internet of things -- the Reliable Actors API is a good choice. It’s designed to work with many independent services, each of which handles its own state and logic. With Reliable Actors you’re able to use the Service Fabric platform to handle concurrency and communication, firing up service objects as required.
At the heart of the Reliable Actors model is an actor service, with each actor exposing a set of public interfaces. These interfaces are probably the most important part of implementing a Service Fabric because they define the messages an actor can work with. Asynchronous messaging is key to managing concurrency in an actor model, so it’s important to get it right.
By mapping actors to microservices to user story actions, you can map your application design to a scalable framework while still supporting automated scaling. Service Fabric handles Actor registration, deploying new instances as needed, with an ActorProxy to help locate actors in fabric clusters.
You can use the ActorProxy to bridge Service Fabric Reliable Services with Reliable Actors, so a Reliable Service can be a consistent gateway to any number of actors -- all while blending stateful and stateless operations on top of scalable, high-availability systems. Because you have no control over the infrastructure you’re using in a cloud platform, having reliability built into the framework is key. For example, the Service Fabric controllers can promote services and initiate new instances after a failure.
The result is a flexible framework for building cloud-scale applications. It presents a very different way of working than building n-tier applications, but once you’ve understood how to map user stories directly to microservice instances, you’ve gone a long way toward building a hybrid actor-service application.
How do we know this model works? For one, Service Fabric is already used by Microsoft to handle the software-defined networks under the Azure platform and in its IaaS offering -- including the service’s distributed load balancer and routing for Express Route MPLS direct connections. Whether you run Service Fabric in the Azure cloud or download and install the beta, the fact that it's already been battle tested is a distinct plus.