 the aforementioned rub. Here's the part where I tell you, I'm definitely going to post my slides on my blog tonight. You're going to check my blog tonight. You're going to check it in a week. It's not going to be there. In a month, you're going to get tired of waiting. You're going to email me. You're going to say, hey, can you post it already? So I have my slides online right now. If you go to robbridge.org, you'll get to this page. Click on Presentations right here. And we're going to look at serverless architecture in Azure. So you can click through, feel free to get ahead, dig into all the things. It's really fun. Who's the guy up on stage? This is a bit about me. I'm a Microsoft MVP. I'm a friend of Redgate. AZ GiveCamp is really cool. AZ GiveCamp brings volunteer developers together with charities who otherwise couldn't afford custom software. We start Friday after work building them software. Sunday afternoon, we deliver completed projects. Sleep is optional, caffeine provided. If you're ever in Phoenix, come join us, because it is a lot of fun. That's the book that I worked on. I worked on Gulp in version two and version three. That was really fun. One of the things that I really enjoy, I posted a comment on the .NET Rocks podcast. They read it on error. They sent me a mug. So that's a little bit about me. My company is Richardson and Sons, Microsoft Partner. I run the SoutheastValley.NET user group, that wonderful Sun logo, and then I'm also associated with the Phoenix Angular Meetup. So we're here to talk about serverless architecture in Azure. We talked about this guy. We're going to keep coming back to this point. I don't want to own that. I only want to own the code that only I can write. When we start talking about serverless, we start talking about what can I offload so that I don't need to worry about that anymore. A brief history of time. Let's start at the beginning. Remember when you went to the store and you got that magazine and it had all of the components in it, and it was really awesome, and you bring that home, and you pick out all of the things that you want, and you craft that perfect PC? That was awesome. And you can have spout your specs, and your signature on the BBS has like 10 lines in it talking about all of the components that you have, and aren't you so proud of that? It was wonderful. Achievement unlocked. Compute count one. Woo-hoo! Let's build our server farms that way. So skipping ahead a little bit, we got to the point where we didn't want to build our computers anymore. We wanted to outsource this to those that would build a black box. They would pick out the components for us. We would buy that black box, which is kind of funny because computers now are black. So we go to PC manufacturers like HP and Dell and Apple, and we get them to pick out the components. We have outsourced the choosing of components. I don't want to own choosing my components. I only want to own my code. So let's take that to the next level. Skipping ahead a little bit in time. I don't want to own the hosting. I only want to own my code. We started out with the server. I love this because this is so representative of the server closet. I worked at a company where all of the non-people things went in that back room. We had the server rack. We had the water main. We had the air conditioning vent. It's really entertaining when the air conditioning from the ceiling dripped in on the server rack. That was a bad day. They're like, but it's all that not people stuff. So we went from the server to a co-location facility where we have many servers. When I moved to that co-location facility, I have outsourced the physical security. I no longer need to keep people out of the building. They take care of that for me. I no longer need to supply ethernet and electricity and cooling. I've outsourced that to them. We went to a co-location facility so that we could get rid of that back room with the water dripping on it. Let them handle that part. Skipping ahead a little bit more, we get to the Cloud. Everything now is the Cloud and what is the Cloud? It's the water that made the servers die. The Cloud is about getting virtual machines faster. Instead of doing that six-month procedure of going through the corporate tribunal to try and get access to a virtual machine, instead we go to a dashboard and we push go and we get that machine a lot faster. Here in this infrastructure as a service mechanism, we've got that provisioning automated. I have outsourced the process of purchasing hardware. Ultimately, that's really cool, but what I ended up with was a faster way to get to a server that I own. At the end of the day, I still have a server. We look at that and say, well, I really don't want to own the server. I want to own my code. We start out with platform as a service, or we move then from infrastructure as a service into platform as a service offerings. Can we get hosting as a service? So what's really cool if you squint real hard, here's our on-premise IIS server dashboard, and here's how I configure my website, and I click through the website, and I have each of those controls. If you squint real hard and you look at that, versus this platform as a service in Azure, here's how I host my websites. I'll take my.NET or Java website and I'll hand it to Azure App Service and it will run it in all the ways that I do. All of these controls that I had are pretty much the same. I'm configuring the different parts of my application, and that looks not unlike this. Well, there's one difference here. As I click through and I get to this button where I have the scale and this is wonderful. This is why we move to the Cloud because I drag that slider from one server to 10 servers and it just works. Now I have 10 servers doing that. Well, what's the server name? What's the DNS? I don't care. I have outsourced running my web server to my Cloud Platform. Any questions so far? Good question. So I have financial data up here on the Cloud. How do I make sure that that data is secure? Good call. So my customers are hitting this web server that's up on the public Cloud. How do I validate that the server is okay, that that connection is safe, and that's where SSL comes in really handy. I would argue of all the places where you're working on securing your web server in your data center or in your server closet, how often are you patching things? How often are you chasing vulnerabilities? Compare that with Azure. How many engineers do they have focusing on security, both physical security and network security? They actually have machine learning algorithms that will watch the traffic to your site and go, I don't think this database query is normal. I think you might want to look at that. So ultimately, yeah, you have to sell that. But built into Azure is a whole lot of business compliance that takes away a lot of that risk for me. The beauty of beauty there is, while I'm in the midst of the audit and they talk about how do you do all the stuff, I'm like, well, here's the page on Azure, go read it. Usually that's the end of that conversation. All of the pieces underneath my application are now irrelevant to this audit conversation. It's a sell and your business may not be perfect for that. But this is a great way to get away from managing my hardware to just managing my applications. Yeah, that's a great question. So I have uneven load, I may have more traffic at the beginning of the month and less traffic towards the middle of the month. That's where Cloud makes a lot of sense, because I don't have to provision for my worst case scenario. I provision for where I am right now and I just dial that slider up and down. What's really cool is I can start to build automation around that to say, well, let's watch the network traffic or let's watch the CPU. Ultimately, the metrics that matter for you are going to be different than the metrics that matter for me. But let's build some automation around that to say, when I notice that my servers are under load, whatever load means to you, let's spin up some more. Whenever I notice that there are servers that are underutilized, let's spin them down. Or if we have a really infrequently used product, it's only going to run the things at the very end of the month, let's shut it down the rest of the time. We have a B2B app, it only works during business hours. Let's turn off the virtual machine at night. Now instead of paying for 24 hours of time, we're only paying for 12 hours of time, and that VM is half the cost, just straight out of the gate. There's some balance there. Somebody's going to try to run the job at three in the morning and it's not going to work. But can we make those adjustments and can we start to provision for our right size rather than over provisioning to match our worst-case scenario? That's definitely what this works for. Yeah, great question. So how do I get data that is persistent across that shutdown process? What's interesting about the Azure virtual machines is that they are persistent. The disk, much like S3, they have Azure Blob Storage, that disk goes into Azure Blob Storage, it is persistent. When the VM pops back up, it connects that disk again and I still have my data going forward. I would argue that when you get towards stateful data, when you get to, I want that database to be persistent. Ideally, you probably don't want to put your database inside of a virtual machine. Instead, you want to leverage a Cloud product, a software as a service, just get SQL as a service. I want a magic connection string that I know works forever, and at that point, then that connection string will continue to go. Whether my virtual machine is alive or dead, whether my website is alive or dead, my database is persistent. The beauty there is that SQL Azure is a little bit more than running a virtual machine, but now I don't need to worry about backups, I don't need to worry about geo-replication, that my data is safe, they've provided for it. So let's dig in a little bit. We've got Azure Web Apps and the cool part about Azure Web Apps is now I'm not hosting the virtual machine, I'm sitting at the layer above that. We hit a few bumps in the road when we did this, and we were going to hit a few bumps here, whether we went from one server to two, or whether we went from on-premise to Cloud, we hit these kind of architectural things where the old way didn't work. Well, what happens if the machine isn't durable? If the disk isn't durable? If the process isn't durable? I've moved from virtual machines to web apps, and so my next request may not start up on the same machine as my last request. So I have a scenario where I've got this app, and I want users to be able to upload their profile pictures. So I get to that point where I'm uploading the profile picture, and I put it in the temp directory, and the virtual machine goes away, and I get a new virtual machine, and the next request goes to look for that image and it is gone. We're going to hit these bumps in the road no matter what, but we need to start thinking differently when we move to the Cloud or when we move to scale. Rather than saving it to the temp directory, I'm going to save it to blob storage to S3. When I save that file to blob storage, now I can go pick that file up at a later date, whether I'm on that server or another server, whether that server has been recycled by the time I get there. It's those types of things rather than storing my data on that machine, I'm going to store it into SQL Azure, or I'm going to write it to a queue. When we get to Cloud Scale and we start thinking in these ways, keeping our data off of the machines, now we get to look towards stateless immutable infrastructure, and that's what's really cool. So we would have hit these bumps anyway. The process isn't durable. How do I communicate between multiple machines on the same network? But we get past that and we start architecting for the Cloud. Ultimately, when we coordinate through queues or through blob storage, now two machines or 2,000 machines can communicate in parallel. So I'm going to take that image upload. I'm not going to save it to my temp directory. I'm going to save it to blob storage, and I'm going to write to Azure queues. I need to go resize that image because of course, they uploaded the five gig image and I only want the 300 by 200 thumbnail. This is one of those more controversial ones. We're going to work towards eventual consistency. The beauty of eventual consistency, I love this model. You go to Starbucks and you say, hey, I want my latte. Imagine they hand you the cup, and then they hand you the steam, and then they pour some milk in it. I don't want to deal with it at that level. Do all the things that you're going to do. I know that you have my credit card and I know that you have my name written on it, and at the end of the day, you will hand me the full cup with the lid on, and that's my latte. Let's write it to a queue. Let's go process that queue. Let's tell the user your order is being processed. We don't need to give them the success or fail right now. But then let's message them in a minute or five minutes when we've completed that sale. When we move to eventual consistency, we also have durability in nodes, because as they communicate with each other, as they go up and down, we can retry a few times. There isn't a user waiting for it right now, waiting to finish that request. Any questions so far? So that's all good and fine, but I don't want to own that. I want to run my service my way. So in the app service model, the web apps model, we had to upload our website to that. Well, I have an application that requires a specific workload. I need Redis or I need this version of this database, and that's when we reach for containers. What's beautiful about containers that infrastructure is code, I can build that container from this text file, I'll version this 20, 50 line text file and it'll be able to build that image in a very consistent way. Unlike the virtual machine where I have to manage all the pieces, I can just build in those plugs, and I can start to host that machine anywhere. Well, it's really cool in Azure, we have the Azure Container Service. Azure Container Service gives us the ability to host these Docker containers in really elegant ways. So I build out my Docker container, and I hand it to Azure Container Service, and I say run it in all the places. Well, Azure Container Service is for the most part, an ARM template. It's a list of hardware that I need to be able to run. By default, it spins up on Linux, but I can configure that to run on Windows as well, and I get to pick from the three major orchestration engines. I can choose Kubernetes, I can choose DCOS, or I can choose Docker Swarm. Once I've made that choice, I can spin up other worker nodes that are Linux or Windows to be able to get the workloads I need. So now I can have my container running my way in Azure, and Azure will manage all of the pieces, make sure I have the right number of virtual machines running. Now on the upside, I now have containers running, I have this Kubernetes cluster, it's doing all the things. On the downside, I've pretty much provisioned quickly, but now I must own these machines. I must patch the virtual machines, I must patch my Kubernetes cluster. I need to keep track of that. So I can take the next step and I can look at Service Fabric Cluster Service because naming is hard, the Service Fabric Cluster Service. The best one is Microsoft created a product, Microsoft ASP.NET Ajax 1.0 for ASP.NET 3.5. Yeah, Microsoft is awesome at naming. So the Service Fabric Cluster Service, it isn't quite the cluster that the name is, but the cool part about Service Fabric is that this is that hosted Docker as a service platform. Now I'm not using the standard orchestration engines, this isn't a Kubernetes cluster, this is a Service Fabric Cluster. But here in the Service Fabric Cluster, I upload my Docker images and they just run. Azure will make sure that I have the right number of Docker containers running at any one place. I don't need to patch the underlying hardware at all. I don't even need to know what it is. I just say this container needs to run on Windows, this container needs to run on Linux, just make it go. Together with the Azure Container Registry, if I don't want to publish my containers to Docker Hub, I can spin up the Azure Container Registry, which is just a specialized blob storage account. I am only paying for that storage. I am not paying for all of the things to manage my Azure Registry account. So now Jenkins spits out images into the Azure Registry. Service Fabric or Azure Container Service spins up to pull in those images from Container Registry, and I have this complete private Docker ecosystem running in Azure. Any questions so far? Good call. So if they're doing all the things in Service Fabric, they're patching the underlying pieces. What happens when a change in that underlying piece breaks my code? Yeah. Sorry. The beauty of Azure Service Fabric is that all of that is removed from me, I have no control over it. One day I wake up and the portal is different. If I want that control, if I don't want to outsource that piece, that's where I reach for Azure Container Service, where I'm starting to run that Kubernetes cluster or that Docker Swarm cluster. Because at that point, I can manage keeping my versions in sync and validating my results. Yep. One day your app is working. If you've built your app to be that fragile based on the underlying hardware, there's probably a bigger problem, but at the end of the day, my app is still down, so my head is still on the chopping block. Yeah. That hurts. Good call. Can I create a QA environment and test things there before it goes into production? I can create two environments, a QA environment and a production environment for testing my changes, but they're going to update them all at the same time. So if I want that ownership, I need to go to Azure Container Fabric, or Azure Container Service. Yeah. Can Azure build the Docker images? That is a great question. We'll look at Visual Studio Team Services for that. That's outside the scope of this presentation, but yes, you could build in Azure those Docker containers if you wanted to. What I usually do is I spin up a Jenkins VM, and I just get the Jenkins VM to do it. So we've got our Azure containers, and we've got our code running our way. But ultimately, I don't want to own that. I just want to own a back-end context. I have perhaps this Windows service that goes and pulls those images that I uploaded and resizes them to do interesting things. I don't want that five-meg image loading on each page load. I only want a small image. So I have this back-end service that does stuff. I want a Windows service in the Cloud, and this could be a Windows service or it could be a Java app. Ultimately, I want something that isn't bound by that browser timing out after 30 seconds and cutting off my job. Here's where I reach for web jobs. What's really elegant about web jobs is it is that Windows service in Azure. Now, unlike Windows service where you have to configure all of the things, a web job is in itself just a console app. It's a console app with a while loop, a console app with a timer. Here's an example of a web job that is pretty cool. Hey, one of my visual studios just closed. So I'm going to go in the other way. Here's a web job. It is just a console app. The beauty of that console app is I can test it locally just as well as I can test it remotely. So ultimately, I upload this web job, this console app, and I can start it either on a timer or based on a web request, or I can have it running continuously. At that point, it just does what it's going to do. Typically, when I build a web job, I'll build a web app that runs continuously. I'll have a timer in that web job that kicks off something every few minutes or so, and then goes and does the action that I was going to take. That Windows service as a service here in web jobs, runs on the full.NET framework, and it does a really elegant job doing that. The other option for web jobs that is really cool is running them as triggered jobs. So unlike the console app here, I initialized a web job host, and then I have this function that just takes in things. So you see here, it says this is based on a Q trigger. So I just happen to have a Q trigger named QNAME, and anytime something gets dumped into that Azure Q, this function will get called automatically. So I don't need to pull against it, I don't need to do anything fancy, I don't need a timer that waits for it. I just say, hey, when something enters this data source, go run that task. So the user uploads their profile picture, I dump the picture into Blob Storage, I dump a message into Azure Q, my web job wakes up, notices that there's something in the Azure Q, feeds it into my function, my function goes and reads that blob and resizes my image. Probably I'm done with that resize by the time that page refreshes on the browser. If not, that's okay, it's an asynchronous process and it could happen in a few minutes or in a few hours or tomorrow or I could run it again in a month. Web jobs based on the full.NET framework gives me that simple mechanism for building Windows services, which is really elegant. Yes, I don't want to change tabs yet. So we dug into web jobs a little bit. Any questions on web jobs? Can I write web jobs in other languages? Anything that can be run can become a web job. So you create a file that says, here's the command I want you to run, and that can be a shell script, that can be a jar file, that can be a bash script, it can be anything that you can execute, you can turn into a web job. That's a great question. Yeah. Is this similar to Lambda functions? It is not. How is it different? Lambda functions will run on demand. This web job will run all of the time, or it'll run on a particular schedule. Let's come back to that when we talk about Azure functions because then we'll start to make a whole lot more comparisons between function as a service and kind of this Windows service as a service. Yeah. What security context does it run under? It is running inside of IAS, but it's not a website running in IAS. So you've got that same security boundary of being in the user land worker process. But because it's not hooked to a web request, it's not bound by that 30 seconds. So a web job is great if you need to run for hours. That's awesome. What's the difference between a console app kicked off by a scheduler versus a web job? I can actually put in Cron expressions to kick off my web jobs, and so ultimately, it's identical. What I love is exactly that. It's a console app. So I'm used to building that console experience. I just don't put that read line at the bottom so that it doesn't exit. I have to wrap that in an if debug because I've deployed a few web jobs that are like, well, they never ended. Oh, yeah, it's waiting for me to push return at the end. But yeah, it's exactly that. I will build my console app. I don't need to do all the funkiness around getting a service to run. I just then schedule it through Azure. Yeah. How do I create that? Is it part of my website or is it a separate service? That is a great question. Here in, did it load? It's going to kick up. I'll have a separate project for my website, and I'll have a separate project for my console app, my web job, and then I'll link them together as part of publishing. So for example, and this is a little bit tiny, but here is my website, and here is a web job. So I'll come into the website and I will say, add project as web job. So here I have the new web job or an existing web job. If I were to choose an existing project, then it'll ask me to pick the project in my solution. Once I've done that, it will link the project, my web job project with my web application, so that when I publish my web application, it'll ensure that my job is built and deployed as part of that package. If my job is built in another technology, then I just need to make sure it ends up in the bin folder, so that as I deploy my app, it goes up as well. That was a great question. Thank you. So web jobs are really cool. Web jobs give me that I'm not running the thing, but on the downside, I still own the process. It's going to restart the process for me, but I'm paying for the process to run the entire time. I don't want to own the process, I just want to own my function. I want functions as a service. I just want it to run. Azure functions are really elegant for exactly that. They're actually built on top of web jobs, and the beauty here is that when your Azure function runs, you are only build as your function runs. Where with a web job, you're paying the entire time. With a function, you're only paying as your function runs. So it's perfect for the things that run infrequently or for gluing things together. The IDE is either the Azure portal or you can use Visual Studio for this, and Azure functions are just beautiful. So let's actually start in the Azure portal. I went into the Azure portal, I went to new, I chose Function, I have no Internet connection, and ultimately I got to my Azure function. Now, this function app is just a grouping of functions. It doesn't mean that this is a security context or a boundary between calling things. It's more just a billing construct, more so than anything. Here's my group of functions. So I'm going to create a new function. I'm going to say I would like a new function, and this wizard is gorgeous in kind of helping you fall into the pit of success. Do I want it to run on a web hook or on a timer or on a data event like dumped into an Azure queue? Then do I want one of these three languages C-sharp, Java or F-sharp? Or I hit the Advanced button. The beauty of the Advanced button is now you have much more languages, you have much more constructs, and so this list then just goes on and on of all of the different ways that you can do things, and other languages as well as just those three. I'm going to go back to the Quick Start mechanism. I'm going to choose a web hook, and I'm going to create this function. Now my IDE is here inside the portal. I'm in Chrome, I'm typing code. When I get done with my function, and I'll just take this function as an example, I will hit Run, and it will actually run my function here in the portal. Here's my logs. So I passed in this request body, I got back status code 200, hello Azure, and then I can see the results of all the things that I logged to that function. If I need nothing more than this, this IDE is great for hacking things together and gluing them together. Once I'm done, I can click on this Get Function URL, and you notice that it has this question mark code equals there. That code is that security piece. So each request to my service, unless I choose to disable it, we'll need a similar code and it's just a GUID. I can come in here to manage those codes and do some interesting things. Let's come back to that one. So instead of saying throw on error, I'm going to go, well, what if you don't pass in a name? Well, if I don't pass in a name, I get a status 400 bad request, and I do that because here in the code it says, well, go grab the name in all the places, either from the passed-in query string or from the post body, and if my name is null, then hand back an error response, please pass a name. So I'm going to say, if name equals null, name equals user. Now still with that blank post body, I'm going to save and run, and now I get a 200. I can put that user back in the post body, and I get a 200 with that value as well. This is great for doing those experiments. I want to glue things together. I want this API to talk to that API and they don't, let me build some glue codes in middleware. At the end of the day, whether I choose this way or whether I want to pre-confiled function, I'm still only paying for usage. So I'm going to come in here to Visual Studio, and whether I want Visual Studio or not, I can get a more compilely, local debuggy type of experience. I said file new project, I created an app function app, and I'll have a similar mechanism. I'm going to say, add new item, I'm going to add an Azure function, and I will say this is GitHub webhook. Now in this case, I chose C-sharp, but I could have also chose any of those other languages as well, and now I'm greeted with that same experience. Here's the Azure webhook. As I push to GitHub, if configured to do so, it will then call into this and I can take action. So it's pulling in that data and perhaps I'm pulling in the first and last name of the committer and doing interesting things. Back here in the portal, I have each function and so in this case, I just have this one function, but if I come up here to the app itself, I now have some of the larger configuration pieces that may be similar to the way I'm looking for them in web apps. So these start to look familiar. Here's all settings, here's where I can configure connection strings and other interesting things. Deployment options, that's where I start talking about slots, where I can have the QA slot and the production slot, and then I'm going to flip them live. All the ways that I can dig into regular mechanisms, I can dig in here to Azure Functions. If I choose, I can create my functions to run all of the time instead of just on-demand. At that point, I'm paying for it much like a regular website, but I have that option to flip into that billing model as well. Any questions so far in Azure Functions? How do I version control when I'm developing in the browser? You don't. So that's a great use case where it's like, well, I want more control over my deployment process. Well, when I'm in Visual Studio, I can do some interesting things like here I would say publish, and I can choose to do that through Visual Studio, or I can have a CI process publish. So maybe my versioning scheme for functions is that I check this into Git and I get Git to kick off Jenkins, and I get Jenkins to publish to the portal. Yeah, so it was late one night and I just needed to make this quick change and so I just logged into the portal and I started changing the code and now it works again right up until you deploy tomorrow. Ultimately, when you want that more control, Azure Functions isn't a great fit and you go back to that where I'm on the website and I'm owning all of that process and I can version things and I can deploy it in really elegant ways. I've lost that build model, but I now have a whole lot more mechanism and I have some and I have C involved in that as well. I don't need to wait for the function to spin up. Great question. Thank you. Should you go into production and start changing things? No. Well, this is what I love, the resume generating events. So it's your head. That's awesome. How do I add third-party libraries or other dependencies to this? If I'm inside an Azure Function inside Visual Studio, then I just have dependencies and I can add reference or manage new Git packages in the normal way. If I'm here in the portal, the interesting thing about the portal is I have, here in this minute, here we are. I can start to define other things that I'm uploading into the bin folder as part of that. So the beauty there is that I can upload anything, I can just reference any DLL that I need to. The downside because it's this looser model, it's great for things that don't change very often or things that don't run very often or things that don't evolve. I just need to make this thing work for now. If you want to look at more durable things, definitely look to Azure websites instead. Yeah. Third-party monitoring tools. That's a great question. What's really cool is this is just a web endpoint, and so you can just hit it with any web endpoint, with any monitoring tool to grab that endpoint. It's a function, so it's going to do its job too. So pass in the fake customer or the fake credit card number so you're not actually running things. But you can also harvest the logs into either Azure Analytics or do interesting things that way. Application Insights is the name of Azure's monitoring system that gives you that holistic view into all your logs across all of your products. So in time, that may be your best way to look at the innards of Azure Functions. That was a great question. Thank you. So I have an Azure Function that's Python or Node, how do I manage those dependencies? What's really cool in Node is I can just upload the package JSON as just another file within my project, and that package JSON can specify a whole bunch of dependencies. In Python, you can do similar things pulling in packages from that package manager. So ultimately, they actually pull in a bunch of Node dependencies for you so that you don't need to try and pull in the normal things. If I want to lean on Express, for example. Ultimately, you don't want to spin up a thing, so Express probably isn't a great solution. But you want to reach into libraries that can execute quickly and then get done. Just put them in your package JSON and it'll pull in it automatically next time it starts. So we looked at lots of interesting things here. We dug into Azure Functions quite a bit. I would argue that Azure Functions is great for single-purpose tasks, for things that run infrequently because you're leveraging that billing model, for things where you just need to quickly glue to stuff together. Maybe great for prototyping as well. The downside, Azure Functions is difficult to visualize. When you have now a container full of 100 functions that do interesting things, how do I know which one calls what? How do I know which handles what data? So I invent a naming convention. I see this as an opportunity to grow, to be able to visualize that workflow, to be able to see functions calling other functions and functions impacting data sources. Because the code is right there, it should be pretty easy to reflect that out. So I don't want to own any of that. I just want my business problem solved. I'm Rob Richardson, I do this for a living and you can hire me. Any questions? Good call. So I go all in, I invest in this great technology, and six months down the road, we decide to kill it. They've given an SLA that they say they will support it going forward, much like they support Silverlight and Windows XP. So yes, your mileage may vary. At the same time, I'm seeing a lot of adoption in Azure Functions and Web Jobs, and so I see those sticking around for a while. At the end of the day though, that's one of the things that we give up when we move to the Cloud, is it will upgrade at its own pace whether we're ready or not. If you want your application to live for a really long time, probably best not to put it in the Cloud. The Cloud moves too fast. Thanks, this has been a lot of fun. Thanks for letting me play.