 Hi, I'm Sean McKenna, a Program Manager on the Azure Service Fabric team. In this video, I'll show you some of the basic commands and tools that you can use to deploy and manage Service Fabric applications. I'll cover connecting to a local cluster, deploying an application, performing an upgrade, and using Service Fabric Explorer. Finally, I'll show you how to perform many of the same tasks on a remote cluster running in Azure and wrap up with some resources to help you get started. Note that in this video, I'll be using applications that I've already built. To learn how to create new Service Fabric applications in Visual Studio, please see building your first Service Fabric application. So we'll start here in Windows PowerShell by importing the Service Fabric SDK module, which provides a set of commandlets for creating and upgrading applications. The next thing we're going to do is connect to the local cluster that's running on my development machine. If you see this type of output when you call Connect Service Fabric cluster, you know that you've successfully connected. Finally, I'm going to create a new application within the local cluster. Specifically, I'm going to create the WordCount application that I built earlier in Visual Studio. This application is actually included as a sample in GitHub, so you can go take a look at the code. Basically, what it does is send a set of random five-character strings into a ASP.NET web API front-end, which are then relayed onto a stateful service for counting based on the first character of that string. So you'll notice that the application has very quickly deployed to my local cluster. At this point, I can perform a set of queries on the state of the cluster and the state of the applications using the rich set of commandlets that are provided by Service Fabric. So for instance, I can say Get Service Fabric application without parameters, which will return me the set of applications that are deployed, in this case, only WordCount. I can drill down further by saying Get Service Fabric service, pass in the application name, and this will return the set of services that are included in that WordCount application, which is a stateful service for counting those words and a stateless front-end that provides that web API endpoint, as well as the web UI. So with that, let's actually take a look at that web UI and the application running on the local cluster. So there are those random words that are being sent in, the total count of words to date, and then the breakdown into a set of four partitions based on the first character of that string. So I mentioned that Service Fabric provides a rich set of PowerShell commandlets that allow you to inquire about the state of your cluster and the state of your applications. You can actually also do much of that management and inquiry through Service Fabric Explorer, which is a web-based tool that's included as part of the cluster and provides both a logical and physical view of your cluster. So here you can see the set of applications that are deployed. In this case, there's the word count application that we deployed. We can drill down just like we did in PowerShell and see the set of two services that are included, so the word count service and the word count web service. And I can further drill down to look at the individual partitions or the individual replicas within a partition. And for each element that I choose in this left tree view, I'm provided with a set of details about it in the right pane. So I can see, for example, the endpoint that it's reachable on, it's health state, and even which node within the cluster that replica is running on in this case. Service Fabric also supports the notion of no downtime rolling upgrades, which we can perform equally on local cluster. And the way that no downtime rolling upgrades work is as the application upgrade is rolling out, Service Fabric performs a series of health checks to ensure that the application is behaving normally as it proceeds through a set of upgrade domains. And so at any point, if the application begins to behave poorly, you can have that upgrade roll back. So let's try an upgrade on our local cluster of that word count application. So we pass in the path to the updated application package. So in this case, it's version 1.0.1, the application name, and then a set of parameters, which include things like the type of upgrade that I want to perform. In this case, monitor upgrade, which means that as the upgrade is rolling out, we are performing all of those health checks before proceeding. So I'll begin running that upgrade. And if I switch back to the application here, you'll notice that while there may be a couple of hiccups momentarily, the application continues to run normally, even as the upgrade is rolling out. And I can take a look at the state of that upgrade within Service Fabric Explorer by going to the applications element in the tree view and noticing here that there's a single upgrade in progress. And I'll see that my word count application is moving from version 1.0.0 to version 1.0.1 and is proceeding through the set of upgrade domains. Finally, let's take a look at how you would do all of this with a remote Azure cluster. In fact, all of the commands that I've shown so far and the tools are exactly the same when targeting a remote cluster. So let's once again go ahead and grab that SDK module and then connect to the remote cluster. In this case, you'll notice it's not running on local host but is in fact running inside of Azure. And I'll see exactly the same type of diagnostic information printed out upon successful connection that I did before. And finally, I'll run the exact same commandlet to perform the creation of that application inside of the Azure cluster. And in this case, I will deploy the version 1.0.1 version of the application and off it goes. And now just like I could do in the local cluster, I can hear say get service fabric application. There happened to be a few more applications deployed to this Azure cluster, but you'll notice the word count application is in fact there. So if we go and now launch the application running in Azure, we'll see that it's exactly the same app that we were running locally previously, same UI, same partitioning scheme, but now running across five nodes that are actually on five distinct virtual machines. And in fact, if I go to another tab and look at service fabric explorer, you'll see that I'm actually running the same service fabric explorer tool except now inside that remote cluster. I happen to have a few more applications on this cluster than I did on my local cluster. But if we drill down on word count, we can see that it's exactly the same app with two services, four partitions, except now if I look at the replicas, I'll see actual end points running on virtual machines in Azure. But this just goes to show that exactly the same PowerShell commands and tools, including service fabric explorer, you can use locally on your development machine and take that all the way up to your large Azure clusters running in production and transfer those skills one to one. Everything I've shown you today can be found in our latest preview SDK. So I encourage you to go get it and get started. We've also built a set of rich documentation and samples to help you learn more. Finally, we'll be looking out for your feedback on MSDN, Stack Overflow and User Voice. So please tell us what you think.