Scale in the Cloud with Azure Service Fabric

The Microsoft public cloud service this year will gain new levels of scalability with the pending release of Azure Service Fabric. It's one of those new capabilities that won't initially appeal to smaller organizations, but will be extremely beneficial to midsize and large enterprises building out applications at a massive scale or even to Internet-scale levels.

Building apps to massive scale for Service Fabric won't be a simple process in that you probably won't be able to take a random application and merely scale it using the service. Developers will have to design the application specifically designed to use Service Fabric.

There are two main reasons why Service Fabric is able to achieve such massive scalability for applications. The first has to do with application design. Modern, highly scalable applications are generally built around the use of microservices.

The term "microservices" has been thrown around a lot over the last two or three years and has taken on several different meanings. From a Service Fabric prospective, microservices refer to independently deployable services upon which developers can build their applications. Microservices can be almost anything. Some common examples of microservices include protocol gateways, queues, caches, shopping carts, user profiles and inventory processing services.

The other thing that makes it possible for applications to achieve such a large scale when leveraging Service Fabric is the Service Fabric cluster. The individual microservices reside inside containers, and those containers, in turn, are deployed across a Service Fabric cluster. A Service Fabric cluster might contain hundreds of servers and tens of thousands of containers. The Service Fabric can scale to such an extent that Microsoft uses it to run widely used applications such as Cortana, Skype for Business, Microsoft Intune and Power BI.

Scaling with Microservices
Service Fabric can run applications at a massive scale because the applications are built to leverage a series of microservices and these microservices are already scaled to a ridiculous level thanks to the Service Fabric cluster. Of course, this raises an important question: What happens if your organization needs to build an application with capabilities for which no microservices exist?

It's important to understand that even though modern, cloud-scale applications are based heavily on the use of microservices, an application is more than just a collection of microservices. After all, you can't just bundle together a collection of micro­services and call it an application. An application needs rules and logic that instruct the various microservices on how to interact with one another.

Microsoft realizes there's more to building an application than just linking to a few microservices. Even though micro­services make up the basis of large-scale applications, the application itself includes other components such as .EXE files, scripts and runtimes.

The thing that makes Service Fabric so significant is it supports all of an application's components, not just the micro­services. Even more important, Service Fabric is meant to be incredibly flexible. For example, an organization can build and run an application on-premises and then later move the appli­cation to Azure without having to make any code changes. Similarly, an organization can build a Service Fabric-based application that starts out small, but can be scaled out on an as-needed basis as demand for the application grows.

Getting Started with Service Fabric
While Service Fabric is geared heavily toward developers, it's a good idea for administrators to have a basic understanding of what's involved in using it. To start off, you're going to need a PC running a supported OS (Windows 8, Windows 8.1, Windows Server 2012 R2 or Windows 10) and a copy of Microsoft Visual Studio 2015. You'll use this PC to install the required runtime SDK and to set up a local cluster.

If you don't have a suitable PC or if your Visual Studio licenses are in short supply, then you might consider using an Azure virtual machine. The Azure virtual machine gallery contains the option to deploy a virtual machine that runs Visual Studio 2015 Enterprise.

Once you have Visual Studio 2015 up and running, the next thing you'll need to do is download and install the runtime components, the SDK and the required tools. These items are available for download and can be easily installed through the Web platform installer. Service Fabric makes extensive use of Windows PowerShell scripts, and the default Windows PowerShell execution policy prevents these scripts from running. If order for Service Fabric to work correctly, you'll need to at least temporarily set the machine's execution policy to unrestricted by using the Windows PowerShell Set-Execution Policy cmdlet.

Upon installing the required components and setting the execution policy to unrestricted, you can begin developing a Service Fabric application. Believe it or not, Microsoft makes this process relatively easy on you because Visual Studio 2015 is Service Fabric-aware. If your goal is to build a Service Fabric application, you can begin doing so by clicking on File | New Project | Cloud | Service Fabric Application. Upon doing so, you'll be prompted to name your project. Enter a name and you're on your way.

Building Service Fabric Apps
In some ways, building a Service Fabric application is kind of like point-and-click application development, because Visual Studio immediately prompts you to choose a template to include in your application. Templates are classified as Reliable Services, Reliable Actors and Web. If your goal is to build an application that's based on the use of microservices, then you'll want to choose either a stateless or a stateful reliable service (yes, stateful services are fully supported).

Upon making your selection, Visual Studio will create an application project. This application project includes references to the services that are leveraged by your application, but it also includes a few other items. You can see the various components that make up the application by looking at the Solution Explorer. The Solution Explorer provides a tree view of the application's individual components including things such as services, publish profiles, scripts and application definitions.

When you eventually finish building an application, you'll presumably want to test it. What's appealing is you can run a Service Fabric application directly on your development PC. As previously mentioned, Service Fabric-based applications depend on a Service Fabric cluster. Visual Studio is able to construct a local cluster directly on your PC. Simply press the F5 key and Visual Studio will prepare the application for debugging and will also build a local cluster. In case you're wondering, a local cluster runs the same code as a multi-server cluster. It's just that the local cluster exists within the confines of a single machine.

The local cluster isn't just an abstract, theoretical piece of software that Microsoft talks about, but you can't actually see. Visual Studio allows you to interact with the local cluster.

The local cluster isn't created until you deploy the application for debugging, by pressing the F5 key. When you do this for the first time, the local cluster will be created in the background. Once this process finishes, you will see a Service Fabric Local Cluster Manager icon appear in the system tray, along with a pop-up message telling you that you can use the Service Fabric Local Cluster Manager to manage your local dev cluster.

You can access basic cluster functionality by right-clicking on the Service Fabric Local Cluster Manager icon. Doing so causes a shortcut menu to be displayed. This menu gives you the option to start or stop the local cluster. You can also use the menu to set up, remove or manage the local cluster. Choosing the Manage option brings up an Azure-like interface that lets you see the resources the cluster is using. You can, for example, see the cluster nodes, the node health, node status and node type. This type of information might be overkill for a single server development environment (although it might be helpful for troubleshooting), but remember that the application may eventually run in a larger scale environment where having access to such information would be extremely helpful.

In addition to basic node information, the node screen also shows you the upgrade domain, fault domain, IP address (or domain name) and indicates whether the node is a seed node.

The Node screen also has an Actions menu that you can use to deactivate the node, if necessary. Deactivation can be performed in a few different ways including pause, restart or even the removal of data. Some Web sites indicate that the local cluster should be removed at the end of each session in an effort to start each day with a clean environment. Keep in mind, however, that it takes a while to set up a new local cluster.

Service Fabric Use Cases
Any organization that develops applications in-house should seriously consider taking a close look at Service Fabric. Service Fabric not only allows developers to leverage the use of micro­services, but also to build self-healing apps that can be run in the local datacenter, in a hosted cloud or in the Azure cloud with little to no code modification. Furthermore, the application architecture allows these applications to start out at a relatively modest size and then be scaled as necessary.

Service Fabric is large enough to support even Internet-scale applications, as is evidenced by the fact that Microsoft uses Azure Service Fabric to host applications such as Cortana and Power BI.