Announcing Service Fabric GA on Azure, Public Preview of Standalone Clusters on Windows Server, and Limited Preview on Linux

At //build 2015, we announced the first preview of the Service Fabric SDK on Windows. In November, we entered public preview for the Azure-hosted service. At //build 2016, we are announcing that both have reached General Availability (GA) and are ready for production workloads on Azure. In addition, we are opening previews of two previously announced initiatives, standalone clusters on Windows Server and Service Fabric on Linux.

Service Fabric GA on Azure

Service Fabric is now generally available for deployment to Windows Server virtual machines running in Azure. This means that you can confidently deploy production workloads and that subsequent releases will offer backward compatibility. In addition to running internally for many years, the Service Fabric private preview program has been operating for over a year with more than 300 customers building applications and services. Many of those customers are now in production or preparing to go live at large scale. The GA SDK (version 2.0.135) is now with tools for Visual Studio 2015, Visual Studio “15” Preview, or on its own.

Here are some of the highlights of this release:

Remote debugging and remote tracing for Service Fabric clusters running in Azure

Service Fabric makes it easy to diagnose and debug applications running on a local cluster, and now you can perform those same actions on remote clusters running in Azure. With the version of Cloud Explorer included in Azure SDK 2.9, you can now view ETW traces from Service Fabric nodes running in Azure and attach the Visual Studio debugger to those machines.



Improved support for dependency injection

We continue to improve our support for dependency injection and inversion of control, allowing you to cover more of your service’s functionality in unit tests. You can now pass in a Service Context (formerly ServiceInitializationParameters) and a state provider for stateful services (ReliableStateManager when using Reliable Collections) as constructor parameters via the registration lambda. See the release notes for more details.


Support for secondary reads using ServiceProxy

Service Fabric stateful services are comprised of primary and secondary replicas, with the secondary replicas kept up to date on changes made to the primary so that they can take over if the primary happens to fail or needs to be moved for some reason. In some cases, you may want to perform reads on the secondary replicas to limit the load on the primary. To date, this has not been possible when using the built-in service remoting and ServiceProxy communication mechanisms. Now, you can specify target options when creating the ServiceProxy, including choosing a random secondary replica for stateful services.

Note that since stateful services follow a quorum commit model, it is possible that the data you read from secondary replicas may be slightly behind the primary, so you should be prepared for stale reads when using this option. If you must have a consistent, perfectly up to date reads, you should continue to use the default behavior, which will always target the primary replica. 

For more information, see the release notes.


Simplified Actor API built directly on top of Reliable Services 

Previously, Reliable Actors were a completely different framework from Reliable Services and included several different variations. Actors have now been unified into a single, consistent model: 


Each of the previous models – StatelessActor, StatefulActor, and StatefulActor<T> - are now simply variations of the single Actor model:

  • StatefulActor: Actor with either persisted or in-memory-only state and 3+ replicas.
  • StatefulActor<T>: Actor with either persisted or in-memory-only state and 3+ replicas.
  • StatelessActor: Actor with in-memory-only state and 1 replica.

For more details on how to achieve of these configurations with the new Actor model, see the release notes.

Backup and restore for Actor services

As a result of the new structure, Reliable Actors are able to leverage the backup and restore capabilities provided by Reliable Services by customizing the Actor Service. See Backup and Restore Reliable Services and Reliable Actors for more details.

General API simplification and consistency

This release also includes a number of other API changes designed to simplify and improve the consistency of the API surface, many of which are breaking. You can find the details of those changes and how to integrate them into your services in the detailed release notes.

: as a result of the breaking changes mentioned above, we will not be upgrading existing preview clusters to the 5.0 runtime. You will need to create new clusters to use the new 2.0 SDK. Going forward, these types of breaking changes will no longer occur. Clusters will be automatically updated and API changes will be staged over several releases using a standard deprecation approach. 


Public Preview of the Service Fabric Standalone Package for Windows Server

Today, we are beginning the public preview for our standalone Windows Server package. This package will allow you to create a multi-machine Service Fabric cluster in your own datacenter or in other public clouds – in effect, anywhere that you can create network connectivity between a set of physical or virtual machines. Once you have set up one of these standalone clusters, it will work just like one that you might have deployed in Azure. You can deploy the same app packages and even publish directly from Visual Studio.

To learn more about the standalone package, including how you can set up your own cluster with it, see Create an Azure Service Fabric Cluster On-Premises or in the Cloud.


Limited Preview of Service Fabric on Linux

We are committed to enabling you to leverage Service Fabric however and wherever you like. Today, we are taking another major step in that direction by starting a limited preview of Service Fabric on Linux, including Java language support for stateless Reliable Services and Actors.

To learn more about our plans for Linux and to sign up to be considered for the preview, please see the Service Fabric on Linux Overview.


What’s next

Going forward, we will continue to publish regular updates to the Service Runtime and SDK. All runtime changes will be backward compatible and will be automatically rolled to your Azure clusters. SDK updates will be published every couple of months and you can adopt those updates at your own pace. Continue to watch this space to learn about SDK updates and to find out when our standalone and Linux previews proceed to the next phase of their path to GA.

As always, we will be monitoring the standard channels for feedback and issues so let us know what you think!

Thank you for your interest in Service Fabric. We are excited to see what you’ll build!


The Service Fabric Team

Comments (8)
  1. AsValeO says:

    “LINQ and System.Linq extension methods are no longer directly available for use on Reliable Collections, although synchronous IEnumerable wrappers around IAsyncEnumerable can be written to enable use of LINQ and System.Linq extensions methods.”

    Could you provide an example of such wrapper please?

  2. Jerome Haltom says:

    Trying to rebuild the way Actor.State worked, with automatic saving after each method. Are there any actor methods that I can use to intercept the enter/exit of a method call, in order to save my custom state object into a ReliableCollection?

  3. AceHack says:

    Is there a go live license for the on premise windows preview version?

    1. Mark Fussell says:

      No, there is not a go Live license on the on premise preview. That will not happen until the summer.

  4. John Azzolina says:

    Will Service Fabric be available in the Central US region?

  5. Jack Bond says:

    “As always, we will be monitoring the standard channels for feedback and issues so let us know what you think!”

    I don’t know about the other channels, but the MSDN forum has gone dead. And the samples appear to be out of date. Service fabric is awesome, it’s just too bad the team isn’t more responsive.

    1. Apologies for the slow response rate on the MSDN forum. We will try to do a better job staying on top of the questions over there. For what it’s worth, we are seeing pretty good pickup in community-driven answers on StackOverflow, so that might be a better option for getting help and advice from not just the product team, but also other users.

      1. Marcel Malik says:

        The same for your UserVoice “channel”:
        Please use it and update your states! There are all outdated and under review since years..


Comments are closed.

Skip to main content