When Microsoft launched Azure, it made the ambitious decision to offer it as a PaaS-only cloud that primarily targeted .Net developers who wanted to build scalable, composable applications. But customers wanted more, such as the ability to upload existing workloads in VMs. So Microsoft started offering IaaS and Azure’s original PaaS was pushed to the sidelines.
Now we’ve come full circle. Customers are gradually realizing that PaaS is key to using the cloud effectively, which is why all the major cloud providers from Amazon to Google to IBM now offer PaaS functionality -- including Microsoft, which recently relaunched Azure’s PaaS in the shape of Azure Service Fabric.
The rediscovery of PaaS stems partly from an evolution in how we think about cloud applications -- and in how we build them. Instead of treating applications as monolithic blocks of code, we’re more comfortable thinking about them as coordinated networks of microservices, a concept at the heart of both AWS Lambda and Azure Service Fabric.
Born in the cloud
Microsoft’s original Azure PaaS was built on a microservices model. It focused on delivering applications quickly while taking advantage of the cloud’s ability to scale. That model remains at the heart of Service Fabric, though you now also have the option to build both stateful and stateless microservices, with support for actors to handle distributed application development.
Originally unveiled as a developer preview at Build 2015, November’s Connect event saw Microsoft open up Service Fabric to more users, with a public preview now available on Azure. But note that Service Fabric has already been proven in action, as it powers many Microsoft services, from Azure Document DB to Intune to Cortana.
You wouldn’t use Service Fabric to replicate existing on-premises applications. You probably wouldn’t use it to deliver existing cloud services, either, at least not without significant re-architecture and a complete rewrite. Microsoft describes Service Fabric as a platform for born-in-the-cloud applications designed to start simply and scale to tens of thousands or even millions of users around the world.
At the heart of Service Fabric are the services needed to manage those applications, with runtime and lifecycle management tools based around containers.
Stateful services and Reliable Actors
The most obvious difference between the original Azure PaaS and Azure Service Fabric is the latter’s support for stateful services. In many cases, applications need to store state between interactions for such activities as maintaining shopping baskets, managing long-running transactions, or delivering online gaming experiences.
Saving state means having storage close by your code, which reduces latency and obviates the need for extra caches and message buses that would add to application complexity. With Service Fabric you also have the benefit of being able to mix stateful and stateless services, so you can use the right model for the right task.
Microsoft is building Service Fabric around a derivation of its Project Orleans virtual actor research framework. Service Fabric’s Reliable Actors offer a distinctive approach to building microservices using clusters of one or more actors as a service.
Each actor has a public interface that defines the messages it can process. Reliable Actors can also have multiple interfaces, which can be useful in a number of cases. For example, you could add a logging API to an actor that processes credit card payments for a shopping cart. Note that Reliable Actors can be implemented as either stateless or stateful elements of a service.
Reliable Actor interfaces are used to pass asynchronous messages using a request-response pattern. It’s a simple model, with each method in the actor called by a request and the response delivered as serialized data. You don’t need to make actors complex; a typical user session might use only one actor. When an actor is called from a client, a proxy handles both the request and the response.
Getting the most from Reliable Actors
Once you’ve written and deployed an actor to Service Fabric, the PaaS management layer will create instances across your clusters as needed. The client proxy handles finding actor addresses and manages how your application responds to failures and failover. The intent of the Reliable Actor model is to ensure the delivery of messages, which can mean the existence of duplicates -- so you’ll need to write code to handle the possibility that multiple copies of the same message exist at the same time.
That contingency ties into the Reliable Actor’s concurrency model, which implements a turn-based approach to reduce the risk of message races by allowing only one thread to run in an actor at a time. If you create actors that handle minimal functionality, you can take advantage of scale to process data in parallel. Each turn needs to be completed before the next one begins, using locks that operate in the Reliable Runtime in Service Fabric itself.
There’s a lot more to Reliable Actors in Service Fabric, but the key message is to ensure you’re using single-threaded methods in your interfaces, and you work with actors to handle the smallest possible granularity of your application’s tasks.
The pleasures of PaaS
Building Service Fabric applications is easier when you opt to use a local installation of the entire platform. You can target this installation with Visual Studio and build and test microservices locally before deploying to Azure. Alternatively, you can deploy Service Fabric on a private cloud in your own data center using Azure Stack on Windows Server -- or build a hybrid application that runs on both your own hardware and on Azure.
One of the key advantages of using a PaaS framework like Service Fabric is the level of automation it gives you. Simply set boundary conditions and let the platform manage application lifecycles; the PaaS scales up and down as necessary and handles the life of any actors you use. Service Fabric also handles failures automatically, restarts failed services, and moves services and containers from hosted server to hosted server in the event of low-level failures.
Service Fabric’s lifecycle management tools enable you to deploy multiple versions of the same application -- for A/B testing, for example, or to offer different geographies different user experiences. The same tools can also be used to partition networks, so you can deploy an update on private IP addresses, run tests, and swap in the updated service for the existing service. Keeping an old version on private IP addresses means you can quickly switch back in the event of problems with the updated code.
Microsoft Azure Service Fabric represents a major, modern rethink of PaaS. With a public preview now available, along with developer tooling and local instances, Service Fabric is well worth considering as a platform for building highly scalable, microservices-based applications. But be sure you’ve broken down your services into simple actors before you start writing code.