Azure Service Fabric is a Relaunch of its Platform as a Service

Microsoft today announced a new version of its Azure platform as a service feature, with the launch of the Azure Service Fabric. Designed to support and manage cloud-hosted microservices written using C++ and .NET, the new Service Fabric supplements Azure’s original App Fabric PaaS tooling.

There’s a lot of complexity associated with building and running cloud services at scale, as Azure CTO Mark Russinovich notes, “Traditional tools have not been up to the job of managing that kind of complexity with reliability and flexibility. So developers have been hand rolling their own systems. The fact is, solutions aren’t really solving the full spectrum of problems developers are facing.”

That’s where Azure Service Fabric is intended to come in, as a layer that Russinovich describes as “really understanding the binding between microservices and the underlying infrastructure that they run on.” While it’s going to be new to Azure customers, it’s not a completely new service, as key Microsoft services are already using it — among them Azure SQL Database, Skype for Business, Cortana, and Azure’s NoSQL DocumentDB service. It’ll initially release for Windows, though a future release will add Linux support, as Russinovich states, “We’ll be addressing start-ups that have chosen to build on top of Linux.”

Azure Service Fabric addresses the management of microservices at scale. If you’re running a large deployment, you’re not going to want to take down all your service instances to deploy an update, as you’re unlikely to know just how many instances are running. Support for automatic rolling updates means that only a fraction of your microservices are down at a time, with Azure monitoring system health during the update. There’s also the option of quickly rolling back to a previous version in the event of a failure.

Russinovich points out that this is the result of years of work: “It’s really hardened by all the usage inside Microsoft. It’s not a version that’s based on the internal bits — we’re releasing what we’re using.”

Support for stateful microservices is perhaps Azure Service Fabric’s most significant new feature. Azure’s original PaaS platform was stateless, which meant that developers needed to build their own tools for handling state. Microsoft is using Service Fabric’s stateful services in Azure DocumentDB, which means that there’s support for a variety of consistency models in Service Fabric, from strong to very weak. What you use is up to you, and for whatever your application needs. As Russinovich suggests, once you’re familiar with the Service Fabric framework, “You can choose to take the training wheels off and party away.”

That means that user state is replicated across the fabric in case of failure. Currently, replication is only supported within a data center, as the default assumes close proximity, though Russinovich notes that there is internal support for replication across rings of replicas in different data centers, though that’s not a typical scenario for most cloud applications. Microsoft is looking at cross-data center replications with higher latencies for future releases, so customers can build more resilient services.

The Azure Service Fabric developer model is based on the same actor pattern that Microsoft uses in its Orleans open source .NET framework. Russinovich is enthusiastic, “It’s definitely a great model for cloud services.” Code will be written in C++, C#, and other .NET languages (including support for Microsoft’s F# functional programming language, which should allow relatively easy porting of Erlang and Scala applications to Azure Service Fabric). While Service Fabric actors are by default strongly consistent, there’s the option to take advantage of the various consistency models offered by the Service Fabric to tune how your application operates.

Microsoft’s Azure Service Fabric runs across public, private, and hosted clouds.

Developers will be able to work with Azure Service Fabric at whatever level they prefer. At one level there are the very low primitives that the Azure Database developers use, and then there are higher level managed services that simplify complex distributed programing tasks. One high level service is a message queue that can replicate messages across the fabric to all the currently running replicas, with no need for developers to keep and manage a microservice instance directory. Russinovich will be going into more detail on the Azure Service Fabric programming model in a Foundation session at this year’s BUILD conference.

Microsoft initially promised that Azure services would be able to run on-premises. While some services were ported to the Azure Pack, it wasn’t a full implementation of the Azure PaaS platform. With the release of the Azure Service Fabric SDK, Microsoft will let you build applications that can run on your own servers and on other clouds, and even as a single server high-density system for development and test.

Russinovich points out, “Our key focus isn’t lock-in.” So setting up your own Service Fabric instance will be relatively easy, a matter of installing the Service Fabric SDK on compute nodes and creating a manifest that details which servers or VMs are part of the cluster. Building a manifest is simply a matter of identifying the servers, and then loading the manifest into Azure Service Fabric. If you want to change the number of servers, you can edit the manifest and Service Fabric will adjust on the fly. A single box deployment can be integrated with Visual Studio, so developers can simulate a large number of nodes and clusters while building and testing applications.

Azure Service Fabric is taking the same microservice approach as Amazon’s AWS Lambda. While Lambda is designed to launch actors written in JavaScript when triggered by an event, they’re focused on managing information flows to servers running on EC2 or to other Amazon cloud services. Even though Lambda is clearly PaaS, Amazon remains focused on offering infrastructure, and any services it offers are designed to support that infrastructure. If you’re using AWS to build a microservice-powered application, you’re still going to need to build tooling to manage your services, containers, and servers, even if you’re using Amazon’s more platform-oriented tooling. As AWS Lambda is stateless, you’re also going to need to build tools to handle state where necessary.

With the rise of the Internet of Things, and the increasing importance of DevOps, taking a microservice-based approach to cloud development makes a lot of sense. Combining it with an actor pattern in order to deliver scalability, while still retaining state and consistency, makes even more sense. Microsoft has made a lot of smart choices in Azure Service Fabric, and it’s going to be interesting to see how developers use them. As Russinovich summed up, “This really democratizes stateful distributed programming, which is the hardest there is.”