About this talk

Azure Service Fabric is the Microsoft microservices framework and this talk explains how to build applications that can be deployed in Azure or on your own infrastructure. Service fabric lets you deploy your own existing services or build them using the service fabric framework to take advantage of the built-in microservices features that service fabric provides.

Transcript

Okay so, this talk is about Service Fabric, so another talk about Service Fabric. We probably need to talk a bit about Microservices first. Then I'll go into how you build things in Service Fabric, and then we'll do demos, and talk about scalability, that sort of thing. So this is a lot more technical than the last one. So I'm hoping my demos going to work. I've got VMware running, and it's not running it really well. So I've got a bit of time to talk. So, hopefully, I've restarted it, and hopefully, it'll be ready by the time I get to that point, but I did say the demos were going to fail, didn't I? So, we'll see. So when we build applications, we tend to do some sort of layered application, so a three-tier type thing. So, traditionally, you'll have some sort of web frontend, some business layer. You may have a couple layers there. It depends and you have some sort of data store, and you, generally, then have multiple machines which we talked about in the last talk actually, and you'll put your application on those relevant tiers. If you want to scale those out, then you'd have to replicate each of those boxes. So your web frontend, you'll build another box, you'll put IS on it. You'll deploy your applications with it, similar with the middle tier and with the database. When you're talking Microservices, you'll take those applications and you'll, generally, break those down into smaller chunks. Now you could do the whole application if you wanted to, if your application is that well architectured, you can split it down. You may want to do that. You may have some things you can take out automatically, some sort of services that you could port to some sort of Microservices framework or you might only have bits of it. So while we've got this replicating and representing your whole application, it doesn't necessarily mean that's what you have to do. It's there. So you'll build these services. You'll push them out onto multiple boxes because they're smaller you can generally get more than one there. You probably have things running at higher density than you would in your previous model, which will actually have multiple applications running in the same sort of space. This is where Service Fabric comes in. So if you're building on a Microservices framework, you could do that now with Web Services in IS. You can have Windows Services running, doing various things, but if you do that, then you have to manage all that yourself. So if you put Windows Service on a machine, and it goes down, you've got to configure it to make sure it pops back up. If it fails for some reason, you've got to look at it, you've got to try and work out why. If the machine it's on fails, you've got to then rebuild the machine and put it on again. So what Service Fabric does is it provides that framework, where you can push your applications into there, and then it manages the lifecycle of that service. So if it falls over, it ultimately spins it up. If the hardware fails, it'll move that service or that service that's on a machine onto another node in the cluster. It allows you to update all your services independently. So you can configure them any way that it allows, as long as you've got more than one instance size, you should be able to upgrade your application without it affecting your services, really. If you've only got one, you've got to take it down and spin it back up. There's no way about that, but it does it. They also allow you to build applications that are either stateless or stateful. And I'll talk about the frameworks that the Service Fabric SDK gives you to help you build those applications. You'll also note that along the bottom, I've got lots of different blobs of different things. So you might be surprised to hear that we've actually got Service Fabric in Azure. Who knew? Let's talk on Azure, Service Fabric. But what it also does is the same executable that they run in Azure, you can deploy into your own private cloud. So if you've got a data center, you've got some virtual machines, on-prem, you can take that same deployment, and push it into your own hardware. Because it's the same set of executables, you can actually push that into Amazon cloud if you wanted or some other cloud provider that's got virtual machines. You could just basically configure those up as a Service Fabric cluster, and you basically push them anywhere. Equally, I've got Visual Studio installed here. We installed the Service Fabric SDK. When I run in the demo mode, and press F5, it actually spins those same executables up locally on my machine, and it runs it as if it was a cluster, an actual Service Fabric Cluster. It doesn't do an emulate like most of the tools do in Visual Studio. It actually runs it locally. So you'll see later, it actually spins up five clusters, a five-machine cluster as a test rig, and it'll deploy the applications throughout, and whatever. It's pretty good. You also might note on the site, it's got that little penguin thing. It's actually you can run Microservices, you can actually run Service Fabric in Linux now. So you can basically build any application in any language, and host it in Service Fabric. And it's actually really flexible, so if you have a lot of Java stuff host still based on Linux, maybe you can pull that over fairly easily. Ooh, I'm going to have to use something else. Sorry about that. So, the one thing I like about Service Fabric is Microsoft are using it for their own applications. So if they're spending the time and effort to build this framework, and they're actually trusting it to run things like SQL Database, that gives it a lot of credibility to me. They've put a lot of effort in it. And if they run those services now, they must've got rid of a lot of the bugs. Because databases need to be pretty resilient and if they're basing their business on it, then that's good for me. I'm quite happy for them to build stuff and test it, and then I'll come along, and use it when it's ready and when it's working. So things like Event Hubs, that has a lot of things happening at one go, so it shows that it can scale. And then we've got... We won't talk about Skype for Business. But Azure DocumentDB is your infrastructure. A lot of this stuff, a lot of the new services are all using Service Fabric under the hood now. So if they're trusting their business on it, then I'm quite happy to trust my applications to it because mine are nowhere, ever going to be anywhere near as big as this stuff that Microsoft are doing. So we're going to have a quick demo now. The first thing I want to show you is if you've not seen Azure, this is the portal that you get. So you do a lot of your configuration and deployment stuff in there if you want. Whatever you can do in the user interface here, there's a whole set of PowerShell and CLI script that you can do automatically. So to base everything around their own API, so you can build everything you see in there, you can generally do, via some API, and probably do more than you can on here. If I want to create a new Service Fabric cluster, I click the plus button and it should come up with Service Fabric, so put in a unique name. Hope nobody's nicked that since yesterday. That's fine. And one of the nice things it does is, I've typed admin in there. It's actually saying username you can't put admin in there anymore. They'll stop you doing that, so you've got to use your own user names now. Similarly, if I do what I did earlier pass that word one, it's doing exactly the same, so it won't let me now do that thing I did previously. So it's actually pretty good there, but it doesn't actually just stop me putting another one on the end. And it also uses Azure Resource templates, so it needs a resource group. I've already got one created, because I've already deployed out, so I'll use mine I've already got. And you can change where you want it located, so I want to put it into North Europe which is actually Dublin, which is a bit weird because West Europe's, Amsterdam. We click on OK, that should take us to the next thing, and this is where we configure up the actual machines. And what you're doing in Service Fabric is you have different application types. So you create nodes, different nodes for those application types. Now I only want one. I'm just going to create the same sort of machine, but you could create a different sort of node types, but depending on what your workload is. So if you've got something that's computer heavy and needs a big machine, you could actually have a specific node type for that, and you can scale these out. Service Fabric will manage where all the applications go based on what node type you configured. So I just want one. I complete the type of machine I want. So let's just give this a name. So we'll say it's a web type and start the [inaudible]. Now this is going to come with a recommended set of machines. It seems to know what I want to use, but when the process should come up here in a second. What I'm doing though is, I don't want any of those because I just want to build a test. I'm waiting for the prices to come up. There we are. So you can see some of these can range depending on what you want to use. They've actually got quite a big range of pricing. So we'll just keep scrolling down, and we'll keep going down, and keep going down. Where's mine, the one I want to use? There it is. That's the smallest you can get. So that's a shared CPU core, but if you want to build something in Azure as a demo for most of things, it's suitable. The other thing I want to do is you've got different tiers of reliability. It recommends five as the minimum, but because this is only a test, I want to go down to three. You can specify endpoints. So if you've got a web app you want to publish out into the real world, you can put the endpoint that you want it to publish that out and you configure that up when you build your application. The next one should be a security tab. I've clicked the right button. I don't want any security. It's only for testing this so I'm not that bothered. And what it's done now is you're just going check, and make sure that I've set everything, and if you notice, it took a little while for the create button to enable. So if I click that now that'll go and spin up that Service Fabric cluster to your machines in Azure. But what I want to do is I can actually download the template, and if you're familiar with Azure Resource Manager, you can actually take this template, and what it does is it allows you to configure your environment. So you can see it's got a few things in there, like a load balancer, the cluster. You can actually configure all these up. So if you actually had, say a machine that you wanted to build in there, that couldn't be put in Service Fabric, you wanted a server with your some legacy application in that only works on the same machine, you can spin that up and deploy your application into there. So, even though I'm building a Service Fabric cluster, I can put other machines in there. I can have different sets of resources that I want. So I can go away and customize that if I wanted to. Then I'd just go and deploy it using PowerShell, and it would go, and build all those machines in Azure, and it will set the Service Fabric cluster up. And also my other machines, it'll set load balancers up or set the security groups up, all those sort of things, if I wanted to which actually gives you quite a lot of flexibility. I've also deployed this on-prem, so when you deploy an on-prem cluster, I've actually created three virtual machines, and I'm hoping that they've all spun up. So I know you can see there, I've got three machines that have Basic Windows Service 2016. I set these up because I wanted to get Docker running in Service Fabric. So I configured Docker on those machines, the Windows servers, and that's pretty much all I did. So I created a base 2016 image. I've got Docker working on that, and then that was it, and then on the first server...so they're what I've called SF-0. I've basically copied all the install files on there, and you get this config file which is a block of JSON, and in there, you'd basically define what each machine is. So that's my machine, I've called the node and the machine the same thing, so each of my three machines that were SF-0, SF-1, SF-2, it's using the same node types. So this is one I set in the Service Fabric config, the multiple node types, these are all the same. I could have made them different, and I'd have a different set of configuration. These two are actually quite important. So I've got fault domain and upgrade domain. So fault domain means that if you've got hardware, you can set it up so that you create your applications, deployed into different fault domains. So if something goes wrong, it means that they're not sharing the same hardware. So if you've got a bigger network than I've got here, you could set that up. But what's probably more important is your upgrade domain. If you've got multiple upgrade domains, it means it will put your services into different upgrade. If you only upgrade your server, then it will upgrade domain one, then domain two, and domain three. So if you've got three instances, it'll take the first one down, upgrade it, put it back, and then take the second one down, and upgrade it, and the third one down. So I actually have an upgrade domains in there. It's actually really useful. So when you configure that up, basically take that thing, copy it back onto the virtual machine, and run a PowerShell script. There's two PowerShell scripts you run. The first one is a test. What it does is it basically takes that JSON file, and goes and tries and connect to all three machines. Then it'll come back, and tell you what's wrong. It's most likely you've got some file reports on it, service file reports. Run it again, it'll pass. Then you run the second one which basically deploys everything, so you don't actually need to go into any of the other machines. You just go and run it from the one. It goes into all the machines in that config, and deploys it all out, and configures up the cluster, and sets everything up for you. Also in Visual Studio, I've installed the Service Fabric SDK . So you install the Azure SDK first, and then you need your Azure Service Fabric SDK, so they're different. But all that means is when I create a new project, they've tried going down the route they've done with ISP.net where you set up a new ISP on that site, it puts its wizard up that allows you pick what you want, the different sorts of things. So, in my cloud options, I've got this Now Service Fabric. When this spins up you actually get a whole set of different services that you can do. So I'm going to talk about stateless and stateful today mainly, but you can have a whole load of other ones. So guest executable is a good one. I'll talk about that briefly. I'll talk about containers, but I won't really talk about these. So what it does is it guides me through the process and it's actually really easy to use. It's all familiar tools. I've not had to learn much to actually use this. I'm familiar with Visual Studio and how to use it, but what this does is it actually creates you a project. I clicked stateless, so it'll create me a project with a stateless service in it which I can just deploy straight out into Service Fabric, and it would run. It would do something. So I've not had to build anything. I'm not having to understand that, how it all works. I can just go and take that template, and actually, deploy and it proves everything worked. So what that actually gives me is, it gives me two things. The first one is the application. So this is basically a set of config files that define what the application is, and then it creates a set of services. So I only picked one service, but I could go into here, click add, new service, and it would pop that same dialog up that we had, and I could pick another service. You have this thing called an application manifest file which basically this defines what your application is, so it says, "This is your application. These are the services in there." And then each service has its own service manifest which basically defines what the service has at the endpoints where they execute it, and that sort of thing, the type. It also creates this stateless class, and what this has is a run async. So it, basically all this does, it's like a thread, a worker thread. So you've just go this little worker literally that does something, right, and all this line does in the middle there is fetch the data out. There's a diagnostic window that pops up which you'll see all these traces coming out. So all this service does is every second, it just increments that iterations that current and displays on the script, and the debug window working. So whatever you do, you can build your application, and put your code into there. So I could take that now and I could actually do that, and customize it for myself. The other thing we have. When I installed the Azure SDK, we got this thing called Cloud Explorer. Let me log that out. It gives me the sort of subscription that my... So I've logged into my machine using my Microsoft account. So it's picked that, and found how many Azure subscriptions I'm subscribed to and it's displayed them. So you can actually see I've got Service Fabric in here, and this is what I've deployed. This is actually deployed in Azure, so you should be able to see that I've got an application in there, and as you can see, I should have three nodes in there. I've also got this because I've installed the SDK, you get this local cluster. So that's what I was saying, I've effectively got the same execute running on my laptop. So if I press F5 on that program which I'll do, it should then go and build the application, deploy it to that local cluster, and we should see, if I looked in here, there should be a local one as well, which is up here, and Service Fabric. So in here, it probably hasn't got anything in it just yet, so it's still building it. So as soon as it starts, we should see it appear in here. What we also get is, I could right-click on here, I could. Oops, I should log that out, shouldn't I? I can right-click on here and open what's called Service Fabric Explorer which I've already got open here. Let me just see if this is actually coming up. Ooh, that might've worked. So, Service Fabric Explorer, if you can see that this says, local host. So that's effectively showing you what's on my cluster on my machine on that demo environment. Because I've actually got it deployed we've got one application there which I can click through, and you'll see that it's made up of one stateless service. So that's that one service that I deployed. If we go back to Visual Studio, we should see that it's actually just doing that increment in that account all the time. So all that is I've run it straight away straight out of the box. There's not been any code change or anything. The nice thing about this Service Fabric Explorer is, I've got it running locally. I've also got it running on that cluster on my machine, so the reboot worked. Hopefully, the next bit will work for this. And this is the same UI that I've got, and the same one that I've got in the cloud. So this one, you can see it's got an Azure URL. This one's got a local, so that SF-0, that's one of my machines in my cluster, and this one's got local host. So they're all the same UI, the same familiarity. It makes it easier to use. What we can do is, I can actually go in here and do some sort of management. So I could go into this node, and there's a few options. So I can do some control a little bit. So if I wanted to restart something or if I've got a machine that's playing up, I could take it out. I could deactivate it, reset it, whatever. I won't do that on my local cluster because I'm just debugging it. So because I'm running it in Visual Studio, I've got the same experience I would do if I was developing any application. So I could go in and I could put a breakpoint in there. So I shouldn't have turned this off. So it's deploying that out against it, so it's going to push that out onto my local cluster. But this should just allow me to break, as you would normally. So you'd expect this to come through, and break when we get there. There we are. So we do exactly the same thing, so you can look at the...there was a watch Windows, all that sort of thing, so exactly the same as you would normally. So I'll take that breakpoint off. What we could also do, if you've got it configured is you can actually right-click and attach a debugger to the one that's running in Azure. I've actually configured this so that when I set it up, there's one of those options on there allows me to enable debugging. See, this won't work in here because I needed to open it in the project that I deployed in there because all the code that I deployed is on that project. I haven't got a share on that code. So what that would do, hitting that would pop up all the processes it can see in that cluster, and you'll see one of the nodes is in there. It's got your application as well. So you can click that, and then run it in the debugger. And you'll then allow it to put breakpoints in so you're actually connected to a running service in Azure which I think's pretty good. You can also do streaming traces down. So if you've got it configured, you can have those logs that I've got coming out of that diagnostic window, you can get them being traced down. You can stream them down. It's the same way you can actually see the login. So it's pretty powerful. So I talked about there's a couple of configuration files in there. So the first one's the service types. This defines what your service does in the Service Fabric. So it explains where the code is. It says what configuration you want, and if you want additional data, it puts that it in there. You wrap that all up, so you have a collection. Basically, you have a set of services, and then you wrap those up in an application. So service type one might actually be part of multiple applications. So the application manifest file basically defines what services you need to compose with that application, and it just wraps those up together. So you can actually have a whole set of different services and different applications, and then deploy them out onto one cluster if you want. There's a number of different ways you can program this. So basically from left to right is the easiest, from a migration point of view to the more complicated. So if you've got things that are services now, so, for example, if you built some services in Topshelf that can run as a command, as a console app, and you can basically configure those up as a guest executable in Service Fabric, and run them straight out with the boxes, without doing any additional code. Similarly, you can build a container. So that's what I'm hoping works because over the weekend, I've built a container that hosts the website, and I've got that deployed as a container host in Service Fabric, running on my local cluster. So I should be able to attach the website and run that from the container. So Service Fabric is managing that. So if that container falls over, it'll restart it, and if that machine goes, it'll pull the image down from the Docker Hub repository, and spin it up, and whatever. So that's pretty good, pretty easy to use. So I can migrate my applications fairly easily using the first column on its own. So a lot of things I've got, I could actually build without having to do anything. If I take the Reliable Services Model approach, that gives me a lot more features there. So I can build stateless and stateful services. So that test app I built, that I justshowed you, that was a stateless service, and that uses the Reliable Services framework, and I want to talk a bit more detail about that. The Reliable Actors is a set of, effectively, templates Microsoft are building to sit on top of these Reliable Services. So Actor's the first one. They've done a Dev CF [SP] one. They've done a web API one, whatever. So this is sort of abstracting again, another layer up on top sort of to make it easier for you to build applications. I'm not going to talk about Reliable Actors in this, because I think there's a lot to talk about without that, at the moment. So when we build something on Service Fabric, all those three models will be getting these benefits, so you get fast deployment. So you saw, even running it locally, it was fairly quick to get that service out there. And it's probably a similar length of time if I want to deploy it out into Azure. It depends how complex your application is. Service Fabric decides where's best to place those services, as well. So, you could say how many instances you want of those services. You may just have a single one because your service you've got will only ever run...because of the way it's written, it can only run as a single instance. But you may have multiple ones and Service Fabric will decide where to place those, and it also manages the reliability. So if something falls over, it tries to spin it back up again. If there's something wrong with that node, it'll try and move the services up onto another node, that sort of thing. So you've got all that robustness built in. It also tries to put as many services as it can in the resources it's got, and it balances those out. So it sort of tries to make efficient use of the resources you've built into your cluster. And as you can see on those screens, we've got those nice little pictures which are all green. And if something had gone wrong, you'd have had red, and I could have drilled in, and looked at where that problem was. So it might be there's a problem with one of the nodes. It might be one of the applications that are being hosted on one of those nodes that's got a problem. Here's what I had earlier. So I had a whole load of red on one of them, and it wasn't really very good, so I had to reboot everything. So it also coordinates the upgrades. So as I talked about the upgrade domains, if I wanted to upgrade my application, it would take them down one at a time and do that for you. So you don't have to worry about any of that. It's really useful, really powerful. So guest executables and containers, I'll show you part of the demo, how easy it is to set these up. But it's pretty much you take your executable, so whatever you've got, if you can run an executable on the command line, then you can run it in as a guest executable in Service Fabric. So I've seen demos where they've run no JS server, which actually is what this example's showing you in Service Fabric, without actually having to do anything other than putting node exe in the file name that you want to run. If you've got something, it generally needs to run in some sort of, like a service where it's got some sort of worker thread type model. Otherwise you just run it, and you stop, and you fall over. It was no point putting it in. But similarly, with containers, you still have an exe host. You have a container host. And you basically appoint it to wherever your image is so that it can download the image and run that, and if you want, need any commands. There's a bit of extra config which I'll show you. It's part of my demo which I hope to map ports across. If you've got exposing ports in your container, you want to map those out to the real world, so people can access it, there's a few bits of mapping you need to do. But pretty much it's just, tell it where the image is and configure that up. Where you get the most power really is if you start using this Reliable Services stuff, so the features that I've showed you when I did that brief demo. One of the things that is important, especially if you're building, like Web Services, is you need to be able to discover the endpoint. So if you're building a web service, and you're hosting it in Service Fabric, you don't know exactly where the Service Fabric has put that service,so you need a way of being able to find that service. So they've got this Service Endpoint Discovery. So if it gets moved, you don't have any hard-coded URLs in there, you'll just go and ask for the end service, and it will tell you where it is at that moment in time. So if something's gone wrong, it's had to move it from one server to another, next time you get the connection, it will give you the new location. We'll also look at how well each of those applications are being used. So each service will run, and you can add extra monitoring in. So you can actually put that instrument in your service and use that to trigger when Service Fabric can move stuff around, so you'll know a bit more about how much load your application's running. And it'll try and balance that across all the nodes in the cluster, so you'll get a fairly efficient way of using the resources. I've talked about the actor pattern. There's also web API and the dev CF pattern. So they're trying to build, Microsoft's trying to build these patterns that sit on top of their Reliable Services. And as you also saw, it's using Visual Studio. It's a familiar environment, F5 debugging, see the diagnostic stuff. It's real easy to use and to package it up, and deploy it. So you could package your application up, use PowerShell to deploy. So I could take that service, the application, run it, compile it in Visual Studio, build it, package that up as a package it, give it to my friendly IT guy with a bit of PowerShell. Say, "Here, go and deploy that on your piece of tin you've got in your backroom. I don't need to worry about it." Or I could do something in my Release Manager, for example, or else just deploy whatever and run those same scripts. They're all part of the framework that you get. So I've been talking about stateful a bit, and stateless. So the example I showed was a stateless service. So if we were building this in our traditional three-tier model, you generally have a stateless web tier, and a stateless computer, and then all your states stored in some data store somewhere, and each of those arrows will add some latency to the journey. So from getting to frontend to the backend, you're going to add these extra hops. You're going to have this extra latency. So you maybe actually put some sort of cache in there to speed that up. But what the stateful does in a computer, in Service Fabric is, is it moves that data store away from your SQL database and puts it local to the computer engine. So it's a different program model to what you're used to, so you might use this as more of a transitionary store. So if you've got some data you want to store locally, then push it out to the database later, you could use a stateful compute. They use that using what's called Reliable Collections. So there's two at the moment. There's a Reliable Dictionary and a Reliable Queue. So if you look at how these collections have evolved over the time of dot.net, you started off with standard collections which basically are single threaded on single machines. And then we went to concurrent collections which gave you that thread safe way of accessing the data in a multi-threaded environment. And now we've come to these reliable connections, which actually run on multiple machines in a high availability scenario. They've got durable storage. It's all asynchronous and actually transactional, which means that whenever you want to access one of these stores, you have to put it in a transaction. So what you can see here is I'm creating a transaction. I'm getting something off the queue, then I'm adding it to a dictionary. So you're basically doing some work in here, and some of that work could go wrong, and if it goes wrong, before you call the commit, it will roll everything back. So eventually it would remove it from each of the dictionaries, and it would actually put the message back on the queue, and that transaction won't be committed. So this commit won't complete until it's copied the data to the main partition, and it also replicates it to multiple ones. So it depends on the size of the nodes, and how many nodes you've got in your cluster. And there's a whole set of rules to determine when it's transactionally safe to say it's committed it to a sensible number of replicas. But let's just say if you've got three, it's going to copy to two of them. It won't return the commit until it's done that. So if something goes wrong with the machine that you're on after the commit, you've still got the data in the other server. You'll then try and replicate them over. So what it does is you have a master node scenario, primary, secondary. So you'll store it in the first node, the primary node. And then as soon as it commits it will then replicate that out across the different nodes in the cluster, so you've got that high availability, that resilience. Similarly, if you've got a machine that goes down, Service Fabric will take those services, and push them somewhere else. It will find the right appropriate clusters with the right sort of node types or capacity, whatever and do that for you. You don't have to worry. I don't have to think about, "Oh, that machine's gone down. How's my service going to run." Service Fabric will move them over. We'd probably have to go and worry about fixing it because if the machine's gone down, I need to sort out why, but in the meantime, my services are still running. I can spin another machine up and add it to the cluster, and those machines, those services will then get spread out over those different nodes. Similarly with upgrading, so if you see, I've got an application here. So here which I'm upgrading, so I'll start the upgrade going, and what you've noticed now is I've got a version two there, and a version one. So you do have to be careful in this scenario because you've now got two different versions of the same service running. If they're storing your stuff in the database, for example, and you've just changed the schema in version two, you've got to make sure that the version one services still work, otherwise, you're going to break everything. So in this scenario, it's fairly straightforward, but if you could imagine somebody like the size of Facebook, if they were upgrading it, you could probably find they've got more than one version of something all other the thing. You've got to make sure that each of those versions is backup compatible with however many other versions that there are there, so it's just something to be aware of. So that's all upgrading there. So, we'll go to another demo. This is if the application that I deployed out, upgraded and deployed on my machine. My virtual machine's running on here, and also, not exactly the same, but nearly the same in Azure. The only difference is I've only got Docker running on here. I've got a whole number of different services running. I've also got a container service and a guest executable service running. So what I've built with this guest executable, I've used the WebJobs SDK, and the WebJobs SDK basically it allows me to build a console app. So I've built the console app using WebJobs SDK. It basically waits for a message to go on a queue and it pushes it onto Service Bus queue. That's what it does. It's fairly straightforward. I built that application separately. I then go into Services here to add...and I've picked guest executable, and now what it does is it says... put applications?" So you do a browse for it, find the application. Then follow it within, click the executable. You can put any arguments you want in there, pick the program, that sort of thing, and hit OK. And what that does is it takes a copy of that if you've set the thing, it creates this guest executable project. It creates a service manifest and you can see, this is all my assemblies. It's put them in there. So when I deploy it, it copies all those files over into Azure. Now similarly with a container, what I've done is I go back in here, do add. It's the same thing. This time I pressed container, and all I did in there was put my address of the Docker Hub where my container runs. So what I've built is a Docker container that's got an IS website in, and it just basically...hopefully, this is restarted. And all it does is when it runs, I get it to print out the machine name that it's running on. So I have three nodes. I have SF-0, SF-1, and SF-2. They're all running on my local cluster here, and you can see all they are is running on different machines. So that is a Docker container running on Service Fabric on my local box. So I haven't got that working in Azure yet. I think I need to configure up the... I just used the default template, and it didn't work, so I think I need to do something with that resource template to get that to work or just do some configuration or something. I'm not sure yet, but I'm sure I'll get that working at some point. So that was fairly easy to do. So I might already have with those two features alone, I could migrate a lot of my applications that I have into Service Fabric without having to rewrite anything. But what I do have is, I do have a lot of services, that dev CF, for example, which I want to move in, but I don't really want to rewrite them. So I have two applications which...sorry. I have one service which is basically that's dev CF service and that's the SQL data layer that sits behind it, so there are two projects. I've just imported them from my application I have already. I have not done any code changes to those at all. I've just put them in there so I can reference them. I've then created a stateless service, so I can host it in Service Fabric. So that's about how to set up. So if I deploy that now, Service Fabric will push that out and give me a dev CF service. It may give me multiple instances depending on how I've configured it, but I won't know where they are. So I've got the whole of the services. All this does is faithfully take documents that we've received from the customer, it stores them in the database. So I need to use that. I let my services to do this. They process the documents, so I need to know how to connect to them. So what I've done is I've got another service which effectively retrieves the documents, and then loads them into the service. So I have this file loader thing, and all this code is just, basically getting messages off the queue, but the bit that's interesting is I need to work how to find it. So there's a whole load of template code that Microsoft have provided which basically creates a TCP binding. You get your current resolver. You say, "I want it to be this dev CF instance." That's the service interface that I've got. And remember I said that there was a unique address? So that's the unique address for this service. So that's the application name, so if we look in the application manifest, you should see that. If you look in the service manifest for that service, you should see that. And then you basically that gets me a client which I can then call them method on. So this bit of code here is pretty much exactly the same code I would've written if I was using a dev CF client in my application. So I've not had to put any connection string in there. That piece of code there will go, and find out where that service is or find that instance of it, and give me a connection string, a connection to that. I can just call the services normal. So for that, I've not had to modify my dev CF service. I've just wrapped it up in this wrapper thing, and I've got it running. I've got it running in the in the fabric. So I talked partly there about configuration. So if I open the application back up and go to the application manifest file, you'll notice there's a whole set of parameters in here. And these bottom ones here are pretty much my custom properties that I want to send into some of my services. Some of the services will use them, and some of them won't. So I've got connection strings there, connections to queues, Redis, Storage Account, whatever. So if we scroll down a bit, we should see different settings. So this is one of my services there, a different service there. It has a different set of settings and the file store one which we saw just had a connection string. So I've defined those properties. If we go back to that file store service, this bit of code here basically goes and says, "Get me the configuration object called config," and I want to get the database connection string out of that. So that's how I pull that data out of those config files. Now when I'm deploying, every time you deploy you have what's called a publish profile, and each one of those publish profiles has a config file associated with it. So, if I go look at the one that's stored locally on my machine, I can see those connection strings there, so I've got a connection string to my local database. I've got Service Bus connection. I've got Redis connection and whatever. So that's configuring it. If I looked at the one that was in Azure, I'd have an Azure database connection, rather than my local one, and I'd have a different set of connection strings for the queues, and whatever. So every time I package up my application, so I right-click on here and do package. Is that going to pop it? Pop it, dial it up, probably not. If I go on here and do publish, that will pop it up. So this has to go on here, it's got a different set of published profiles. So I pick my demo one, it's pointing to my machine or my local VM. It's saying use a demo XML file. So I can set this up. I can practice that up with each of those. So I want a package for my Azure that I want to push in, give it out to my IT guy. Then I would package it up as the Azure one with the Azure XML file, and that would package that up and you'd be able to deploy that. There's, actually if we go to the scripts folder in here, there's a deploy PowerShell script. So you basically run that past the right parameters into the right files, and that will deploy out to Azure. Let's go back to the demo project. So in this application, I created a stateless service. I can equally do the same thing and go in here, and do... Wrong one. Hit add. I can go in and add a stateful service. So, again, this is going to create another service in the application, this time a stateful one. It'll do all the templated code for me, and, again, I could just publish that out straight away and it would run. I won't have to do anything. But what it's actually done is, again, it's created this stateful class. It's got that run async in there, and this time it's using a dictionary. So this is using that Reliable Dictionary so it pulls that dictionary out. I gave it a unique name and in order to use it, I have to use a transaction. It won't let me access it without putting a transaction in. So we create this transaction around the code. I'm doing something with it. I'm pulling the data out. If it's got a value, I'll print the value out. If not, the value doesn't exist, I then increment it. So pretty much the same as what the other one did, but this time it's stateful. So what that should mean is if things go wrong, I don't lose that data. To find out, hit F5, and deploy that out. So this is what this will do now is it will take my... So if we quickly go back to Service Fabric Explorer local host, I've got nothing in there. So I've got five nodes, but I've got nothing, no applications running. So, hopefully, when this actually deploys... That didn't work. That's the wrong one, anyway. So that's running now. So that should, I've now popped up one. So that's now deployed that application out. So every time I stop debugging, it removes it out of that cluster, and every time I start. So if we go into that application we should now see it's got two services in there, and add one, so it's got that stateful and stateless. I should get my Diagnostics Event window. Let's get rid of that there. And now you can see that this is scrolling up with different values. So the working dash is the stateless one. The current value is the stateful one. So if we go back into here, and look at the nodes, you can see what's deployed. So that's got stateful in there. [Inaudible] This has got stateful and the stateless in there, so I should be able to click through each one of them. So this one on node three is the secondary one, so this one should be the primary one. So what I can do... where are we? There's the stateless one. So this has only got one instance running. So if we just go back quickly to here, and see that we're looking at, it's up going on for 100 now. So next time, yeah, it's on 100. So if I go and do a restart... underscore... Is it two or three? It's three. So that should now restart that thing. So what we should see in Visual Studio is, you see this is now...and it's done something there. You see it caused it. We've lost the working node and now it's come back, and it actually has restarted it. I'll just pause that a sec. So it's restarted it because that was stateless and I restarted the server, it didn't have it stored. So we couldn't do anything about it. I'll keep that off again. So you can see this one's now, the stateful ones up at 150-odd. So if I go and look back to that... I'll get rid of that because that's just annoying me. So that's restarted, you've got that same executable, you've got the same experience. And it runs on Windows and Linux. You can program in any language. So you've got Java and Linux will run. If you've got C Sharp, dot.net, node, whatever, you can build applications. You can host them in Service Fabric. I've showed you the Reliable Services and how you get quite a lot of benefits from building that, and you get the stateful and the stateless. And I've shown you the differences between what events are for each with those, and I'm showing that Service Fabric when I was resetting those servers, it automatically spun them up elsewhere, and it moved the replicas around, and it did all that health stuff that I didn't have to worry about. So it's actually pretty good. And I think, to me, the fact that Microsoft uses it, and they're betting their business on this service, this technology, then I'm quite happy to use it myself. I'm quite happy for them to go and build all their services and get rid of all the bugs, and I'll take the benefits that they can get. I think it gives them credibility if they're actually prepared using it themselves, and that's it. Thank you very much.