Azure Service Fabric: What you need to know

Cloud services like Azure are at heart massive distributed systems, hosting all manner of services. Some of them are hosted infrastructure, some of them are containers and microservices, some are development platforms, and some take advantage of serverless patterns.

They all need one thing: a management and orchestration platform. General-purpose cross-cloud tools like Kubernetes offer one road to delivering a managed container environment, but there’s also a place for custom environments that focus on the needs of a specific cloud platform. For Azure, that’s handled by a tool that’s been there since the earliest days of Microsoft’s public cloud: Azure Service Fabric.

Introducing Azure Service Fabric

Hidden away in the foundations of Azure, Service Fabric can be hard to describe. But we see it all the time, in the tools we’re using to build our own cloud-native software. It’s at the heart of Azure’s Event Hubs and IoT platform, its SQL and Cosmos DB databases, and many of the enterprise and consumer services we use every day. With Azure Service Fabric, you get access to the same tools that Microsoft uses to run and manage its own services, building them into your own code.

The intent of Azure Service Fabric is to make it easy to deploy and manage microservices, handling both stateful and stateless operations across a PaaS Azure instance. It’s not only for Azure, because the local development tool is a complete version of Azure Service Fabric, which means it’ll run on any Windows system. A Linux version makes it portable across multiple clouds as well, handling existing and custom code.

Azure Service Fabric manages your application life cycle, with APIs that give additional platform access beyond purely standalone code. It also supports its own actor/message microservices as well as hosting ASP.Net Core code. Services can run natively as processes, or you can host them in containers, giving you the option of quickly bringing existing code to Azure’s PaaS. Containers mix with other Azure Service Fabric application models, letting you quickly include existing functionality via lift-and-shift or by including specific packaged applications.

Get started with Azure Service Fabric

Perhaps the quickest way to start developing with Service Fabric is its Reliable Services framework. This is a set of APIs that integrate with Azure Service Fabric’s application life cycle management features. You can write code in any supported language, or in your choice of application framework. Services can be stateless or stateful, with stateless services using external storage to handle state. The stateful option is more interesting, because it uses Service Fabric’s own tools to manage application state. You don’t need to consider scaling or high availability; it’s all handled for you.

If you’ve used C#’s collections, you’ll find the Reliable Service’s Reliable Collections familiar. They’re also held in the same instance as your compute, reducing latency. If a service fails, it can pick up state on relaunch. Having different state models lets you choose the model that works best for your service. Simple services that only require input data to operate can be stateless, but if you’re working with code that needs to know previous state, you’ll need to build a Reliable Service.

Microsoft makes it easy to build familiar web and application back ends on Azure Service Fabric with support for ASP.Net Core. Although it’s not 100-percent code-compatible with ASP.Net MVC, you can migrate existing code to the new platform. There’s support for building both stateless and stateful services, handing over application orchestration and scaling to Azure Service Fabric.

Scalable concurrency with actors

Born-in-the-cloud applications should take advantage of the Reliable Actor framework. This extends Reliable Services to implement virtual actors (as used by the open Project Orleans framework that’s popular in gaming back ends). Using the actor/message pattern to handle microservices works well, because its underlying concurrent systems model scales rapidly and can handle many actors operating at the same time.

Reliable Actor isn’t for every scenario. It works best when your code can be broken down into simple blocks of compute that can be implemented as nonblocking single-threaded objects that have either no state or hold their own state. It’s best for completely new applications, because it’s hard to decompose existing code. Building an application using Reliable Actor can be complex, even when you have defined your actors. You need to keep in mind that while actors can be garbage-collected, their state will persist and is accessed when you call an actor with the same ID in future.

Reliable Actor solves many complex distributed computing problems, though you’ll need to think carefully about how you map objects to actors, and how you’ll use them in your applications.

Azure Service Fabric goes open source

Microsoft has recently announced that it’s open-sourcing Service Fabric, changing the development model to one that will accept third-party pull requests, as well as allowing for a public, open design process.

Shifting to an open source development model, alongside an open design process, is a massive undertaking for a foundational technology like Azure Service Fabric. While the initial tranche of open source code is Linux-based, the Microsoft development team has indicated that the Windows-based code that currently runs on Azure will follow soon. Development will be on GitHub, with much of the initial work focused on completing the transition from Microsoft’s internal platforms to a public-facing process.

Microsoft has planned to deliver an open source Azure Service Fabric for some time now—at least since the start of the Linux branch of the code. Because it’s both newer code and uses a different tool than the Windows version, it’s been a lot easier to get that branch into shape for public release. The Windows tool is more complex, with a decade or so of history that needs to be unraveled and refactored. Much of that is due to the use of Microsoft-only development tools not available to the outside world, plus the rework required to move it to publicly available tools.

Having a tool like Azure Service Fabric at your disposal gives you many more options than traditional PaaS, especially when building new applications from scratch. Support for containers adds the ability to bring in packaged applications alongside your code. Similarly, using familiar frameworks and patterns can shorten the learning curve. With an open source future ahead of it, Azure Service Fabric could be the multicloud application framework you’re looking for.