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.
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.
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.
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:
- 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.
- 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
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.
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.
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.
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.
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