Service Fabric Enters Public Preview


Since we launched the Service Fabric SDK for one-box development at //build 2015, the most common question we’ve received is “When will I be able to create a cluster in Azure?” We are pleased to announce that the answer to that question is “Today”. Along with opening up the ability for you to create clusters in Azure, we are releasing a significant update to our SDK, documentation, and samples. This post will review the highlights of what we are releasing today. We will go into further depth on many of these topics in subsequent posts.

By the way, if you're brand new to Service Fabric, check out the overview video here.

 

What's New

Create Clusters in Azure

You can now create multi-machine Service Fabric clusters in Azure, allowing you to easily expose your applications to the world and to begin testing for scale. Clusters can be created in several different ways: from the Azure Portal, in PowerShell, and in Visual Studio. When you create your cluster, you will choose the number of virtual machines to assign to it. You can subsequently scale the cluster up or down by adding or removing VMs.

 

Please note that while usage of Service Fabric itself is free, you will be billed for the resources consumed by your cluster, including virtual machines and storage.

Party clusters

Want to test drive the experience of deploying applications to and managing Azure clusters before starting to incur charges? Today, we’re releasing a pilot program known as “Party Clusters”. We will have a rolling set of five-node clusters in Azure that you can sign up to access. All you need to do is provide your email address and complete a captcha and you will receive the endpoint URL of a non-secure Service Fabric cluster that you can connect to free of charge. Each of these clusters will only last a few hours, at which point they will be torn down and all of their data will be deleted.

To start partying, go to https://aka.ms/tryservicefabric.

Also, it should come as no surprise that the party cluster infrastructure is itself running on Service Fabric. Since we thought it might be interesting for you to see how we did things and possibly set up your own party cluster service, we’ve open-sourced the project on GitHub.

 

Web-based Service Fabric Explorer

The Service Fabric Explorer tool has been moved into the browser and into the cluster. Now, rather than requiring a client tool to be installed on your PC, you can inspect and manage your cluster from any device that has a web browser. Simply navigate to http://<clusterendpoint>:19080/Explorer (https for secure clusters).

 

To learn more, see Visualizing your cluster with Service Fabric Explorer.

Note that the web-based Service Fabric Explorer has not yet reached feature parity with the rich client version. We will continue to ship the rich client with the SDK until it does. 

 

ASP.NET 5

Service Fabric now includes integration with ASP.NET 5 making it easy to add a web UI or REST API entry point to your application. When you choose to add an ASP.NET 5 project to your Service Fabric Application, you’ll be presented with the same set of templates that are provided for standalone ASP.NET 5 projects. They have simply be augmented to include a PackageRoot folder (for storing the service manifest and any data/config packages) and to include an additional NuGet Package – Microsoft.ServiceFabric.AspNet.Hosting – which serves as a bridge between the Service Fabric runtime and the DNX runtime.

This release is compatible with ASP.NET 5 RC1, which you can get here.

 

Local cluster management from the system tray

You can now create and manage your local development cluster using a system tray application, the Local Cluster Manager.

 

The application will launch automatically when you deploy an application from Visual Studio or you can launch it directly from %programfiles%\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager. 

 

Visual Studio improvements

Publish to remote clusters

Now that you can create clusters running in Azure, Visual Studio naturally supports deploying applications to them. Simply right-click on the application project and choose Publish. You will have the opportunity to choose a cluster based on the subscriptions associated with your Microsoft Account.

 

 

 

Per-environment application parameters

Now that you may have many different clusters to deploy to, you may want to create different application configuration values for each of those environments, including your local cluster. The application project provides an ApplicationParameters folder to house these configuration files, which can be used to override the default values for the application.

See Managing application parameters for multiple environments for more information. 

 

Manifest version editor

Service Fabric supports independent versioning of services and individual code/configuration/data packages. However, managing changes to those versions can get complicated as your application grows. Visual Studio now includes a manifest version editor that can simplify the process. By default, the Visual Studio project templates now start every version at a semantic versioning-friendly 1.0.0. If you stick with a 3-digit semantic versioning scheme, the manifest editor will automatically roll up any changes made to a package to its containing service and application.

 

Publish application upgrades

By default, deploying an application from Visual Studio involves completely removing the previous application package and replacing it with a different one of the same version. You can now publish application upgrades directly from the Publish dialog.

Note that you must change the versions of the packages/services you changed, along with the application version in order for the upgrade to succeed.

To walk through a full application upgrade, see the application upgrade tutorial. 

 

Preserve data on start

For stateful services, it is often necessary to load a significant amount of data before testing and debugging can be meaningful. Previously, you had two options for doing this. You could reload your test data on every F5, but that would lengthen the time before your app was ready and it didn’t preserve data that you might have input manually. Alternatively, you could perform an app upgrade but you typically don’t want to be changing version numbers on every F5 and you’ll be biased towards speed over safety, contrary to what you want in a real upgrade.

To simplify this scenario, we now offer the ability to “Preserve Data on Start”.

 

When this project-level property is set to ‘Yes’, we perform an upgrade on your behalf when you hit F5. The upgrade avoids the issues cited above by:

  1. Automatically modifying your app/service/package versions but only in the pkg output folder. Thus, you can F5 all day long while preserving your cluster data and only make the version changes that will go into source control when you’re actually ready to publish a new version.
  2. Using the fastest possible upgrade option (UnmonitoredAuto) along with a series of other tweaks to optimize for speed over safety.

Please note that because of #2, data loss is possible (though unlikely on a local cluster) and thus should not be used if that risk is not tolerable. 

 

Reliable Actor improvements

Dependency injection

To enable unit testing of Reliable Actors, we now offer the ability to inject dependencies from the Actor constructor.

Consider an actor called MyActor which has some external dependency implementing IDependency.

 

For hosting the Actor in service fabric, it must be registered with ServiceFabric as follows:

 

For unit testing dependencies can then be injected as:

 

 

Actor type and interface hierarchies

You can now create a hierarchy of actor types and interfaces. For example, you might layout an interface hierarchy like so:

For more details, see Polymorphism in the Reliable Actor framework

 

Granular state management

Previously, your only option for maintaining state in actors was to use StatefulActor<T>, which required a full deserialization/serialization of T in order to read/write actor state. In this release, we’re adding the ability to manage actor state at a more granular level. StatefulActor<T> will remain for cases where your actor state is small and simple but you also have the option to create a non-generic version, in which case you can use the StateManager type on the base class to manage a set of named states.

 

Reliable Services improvements

Multiple communication listeners

Service Fabric provides flexibility in the type of communication channel that you expose from your service, but previously you could only create one type of listener per service. With this release, you provide multiple listeners for a single service. For example, you might want to expose your service via a RESTful WebAPI and WCF.

For more details, including code snippets see the Reliable Services communication model.

 

Breaking Changes

We have made some changes to our API surface to make the programming model more consistent and intuitive. The largest proportion of the changes is associated with a refactoring of namespaces into client, runtime, and specific-implementation that is a primer for a future release where that breakdown will align with a distinct set of NuGet packages. In addition, there are a number of type and method changes to make names more consistent and account for new features. We will follow up with a detailed post on the changes and where we're going with the APIs. In the interim, please take a look at the new project templates, samples, and documentation for guidance.

 

Documentation

We have made significant updates to our documentation, including tutorials and conceptual content as well as managed, REST, and PowerShell reference documentation.

If you are new to Service Fabric, one of the best ways to get started is by following the learning path. If you are looking for reference content, you find it linked from the left-nav at https://aka.ms/servicefabricdocs.

 

Samples

Our samples have been reorganized, expanded, and integrated with the Azure Code Samples gallery. Look for follow up blog posts covering some of the new, larger samples in more depth but for now you can find everything at https://aka.ms/servicefabricsamples. And as always, we are accepting pull requests.

 

What’s next

In mid-2016, we will exit preview and become generally available. Between now and then, you should expect SDK refreshes with new features and bug fixes roughly every two months. During that time, we will be monitoring your feedback closely to help shape our GA release so please let us know what you think through any of the following channels:

 And please do stay tuned to this blog as we will be publishing a series of posts covering these topics and more over the coming weeks and months. Until then, happy coding!

The Service Fabric Team


Comments (9)

  1. Matt says:

    I can't wait to start playing with Azure Service Fabric, I was really hoping there would be a low tier option to Develop on for those of us with limited infrastructure. I went to spin up a cluster and start playing today, but the minimum was 5 A1 VMs which would be over $200. Any chance we could get a lower end tier or tone it down to 1 VM to get familiar with the platform with the ability to scale it out? I would want to prove out how it would tie in with our deployment process etc.

  2. Matt says:

    For my above comment I ended up creating a UserVoice item people can vote on to see if others would like this ability:

    feedback.azure.com/…/10765014-lower-end-pricing-to-get-familiar-with-the-framewo

  3. Mick says:

    Hey Matt – try the web platform installer and search for 'Azure Service Fabric' you should get the installs there.

  4. wjsazure says:

    @Matt.  Agreed.  I see $334 for 5x$66.96 A1 nodes.  You getting a deal?

    I also find it a bit confusing to demand a min 5 nodes for a preview.  I understand a 1 node cluster probably defeats the purpose, but 2 nodes should work.  I suppose there was a specific reason for it beyond arbitrary.  Maybe it is a way to scale up slower using pay-for-play as the lever.

  5. We hear you on the cost of getting started. That's why we're providing the "party clusters" as a place to kick the tires on a multi-machine setup.

    We are also looking at smaller configurations that you can run within your own subscription, but realistically the smallest we are likely to go is 3 VMs – voting algorithms like odd numbers. 🙂

    Do keep in mind that the local cluster is NOT an emulator or simulator. It is the real runtime, with 5 nodes squeezed into a single machine. Thus, there wouldn't be all that much benefit from a two VM cluster compared to your dev machine.

  6. Moog says:

    Yes! I can't wait writing code for Service Fabric. The support for DependencyInjection in an Actor is great. I hope that this will work for services too. First I'm going to migrate my prerelease code to the preview version.

  7. Matt says:

    @ Mick – I tried the platform installer, but it requires "Windows Operating System 8 or Higher". My company has everyone on windows 7 boxes still. Thank you for bringing attention to this option though.

    @wjsazure – I am using an MSDN subscription which gives a discount on the services (azure.microsoft.com/…/msdn-benefits-details). "In addition to the low dev/test rates on VMs, you also get low rates on Cloud Services, HDInsight, and Web Apps."

  8. Moog says:

    Today i tried to deploy a Stateful Service Applicatiion that was created out of the box from VisualStudio to my ServiceFabric Cluster on Azure. I did not make any code changes. Now I get the following error: "The Load Balancer has detected a Constraint Violation for this Replica". The deplyoment to my Local Cluster works fine. Has anybody an idea what causes this error?

  9. Preetham Reddy says:

    Hey Guys,

    We've reviewed the Service Fabric and are very interested in using it in our next project.  We are making some decisions and wondering if this would be generally available around April 1st week. That's when we are planning on going live.

    Another thing to note, is it PCI compliant? I know Azure cloud services are PCI complaint and I don't see any reason why Service Fabric shouldn't. Just want to make sure I understand this before spending huge amount of time investing in developing our application on Service Fabric.

Skip to main content