Building Real World Cloud Apps with Windows Azure - Part 1
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Guthrie, Scott
This two part talk will explore how to build real world cloud applications using Windows Azure. The talk will cover key patterns of cloud computing including: - Automating Everything, - Source Control Best Practices, - Continuous Integration/Delivery, - Enterprise Identity and SSO Integration, - Web Development Best Practices, - Data Storage Options We’ll discuss each of the above cloud patterns in the talk, and then demonstrate how to really use them by walking through real code that shows how to leverage them within a Windows Azure application.
 Thanks everyone for coming to NDC. This is my second time here and really excited to be back and want to thank everyone for coming out this week to the conference. It looks like some great speakers and great content throughout the week. My name is Scott Guthrie. I work at Microsoft on a couple different things, one of which is Windows Azure. What I'm going to do is spend this talk and the next talk kind of walking through a new talk that I've never done before, so I'm pretty excited to give it, which is basically called Building Real World Apps with Windows Azure. It's going to be kind of a patterns-based approach and I'll kind of walk through exactly what I mean just in the next couple slides. That walks through kind of how you build real world cloud-based solutions and the patterns are going to talk about apply to any cloud environment. You can use them with Amazon, you can use them with Google, although I'd really like it if you use them with us. The demos I'm going to walk through are going to be using.NET and Visual Studio and using Windows Azure to kind of show off how these concepts work and hopefully make them really real. How many people here have used Windows Azure? Okay, good. A lot of people have. A few people haven't. If you haven't, don't freak out. I'm going to provide enough context hopefully throughout the talk that, oh yeah, two bottles of water. Thank you. Even if you don't know what Windows Azure is, hopefully you know what it is at a high level, but if you don't know it from a practicality perspective, you'll still be able to kind of benefit and pick up a lot of things here. In terms of, so I'm going to spend 115 slides walking through patterns of cloud computing. I thought I'd just kick it off though first by walking through, first, what are some of the benefits that cloud computing gives you? Every time you want to learn new things, you might ask yourself, why am I learning it? I think ultimately cloud computing is exciting for a number of reasons. One of the reasons is as developers, it just lets us do more. It lets you reach your customers in a deeper way. You can build more engaging experiences. You can do things like mobile. You can use things like analytics to have a much richer customer experience. You can reach other markets with cloud computing because there's data centers around the world. You can very easily expand your business into new geographies. You can deliver things that just weren't possible today. We're going to build a simple solution today and walk through some of the concepts of it. It looks pretty small. It is a relatively small app. The nice thing about the way we're going to build it is if we wanted to build it so that we stored hundreds of terabytes of content with it, we could. If we wanted to build it so that we could run it across a thousand servers, we're going to architect it such that we could. It lets us approach problems that previously were just not practical and are now real. It's going to do it in a way that's cost effective. The app I'm going to build, you can basically develop and test it completely for free. Everything we're going to build, you could do it no cost whatsoever. The nice thing about cloud computing and Windows Azure is you pay only for what you use. As your app grows, as the amount of storage grows from a couple megabytes to a couple gigabytes to a couple terabytes, you're only paying for what you're actually using and you're not having to preallocate a lot of resources, which also, in addition to the technology from a business model perspective, again, enables you to kind of build apps that otherwise you might have a hard time getting your company to approve. Hopefully, you'll see at the end of the day, it's a really rich, flexible, and ultimately very agile environment that as developers ends up being fun. What I'm going to try to do today is walk through what I'm calling common cloud patterns that will help you be successful targeting this environment. Specifically, I'm going to walk through a simple app. I'm calling it Fixit, which is a very simple app, but it shows off a number of these patterns. It shows off data access. It shows off security, including enterprise, single sign-on with Active Directory. It shows off queuing. It shows off, we'll talk about caching, and we'll talk about telemetry and monitoring and logging and a whole bunch more. Specifically, here are the 13 concrete patterns we'll walk through, both this first talk and then the second talk. Using this code as sort of an example, and hopefully, you'll arm you with kind of the knowledge so that if you took the slides, took the code, you could go off and you could build pretty much any type of web or mobile-based application using these patterns and know that when you deploy it and run it, you'll be successful and hopefully have a really agile development environment that lets you kind of reach and build these types of new solutions. These are kind of the patterns we'll walk through. We're going a lot more depth on each of them throughout, and basically we're going to use kind of explain the concept and walk through code and hopefully make it real for each of these. A quick, simple demo of this app that we're going to walk through. Again, it's a pretty small app. It's called Fixit, and I'm not sure if Fixit translates well in Norwegian, but basically think of it as a ticketing system where you can go and you can say, I need something fixed and upload a ticket, and then someone can go ahead and process it and do something with it. So it's not a very complicated app, but the idea is you could go to it, you could log in using a forms authentication and a database, or what I've also wired up is supports that I can do enterprise single sign-on with Active Directory. So what I just did was redirect it to my company's portal, or sorry, company single sign-on. I'll walk through how you do that yourself, I can spell Microsoft correctly. And so basically I just logged in using my company security model. I can say, pick up room. My room is a mess. I'm going to sign it to myself. I'm David, but let's see. Trash, there we go. If I can upload a picture of what I want to get fixed, I can go ahead. I've uploaded it. I could create more tickets if I wanted to. Clean close. Please they smell. Signed it also to Scott. Again I'm logged in as David. And so forth. So that's the progress of the items that I've done. You can see I have a few, one that I've been working on last night. And then basically I'm just going to log off out of this application. And I'm going to log back in this time as me using the integrated off. So no single sign-on here. When I log in now I can see what issues are assigned to me. You can see David assigned to me. I need to clean the close and I can see a picture of my dirty close. And I could say they do. Market fixed to close it out. So again, very simple application. Not a huge in-depth app. But one that is rich, hopefully you can look at and say, yeah, I could build that. And what I'm going to do though is try to show you then how you could build this simple app but incorporate all these patterns as part of it. So that it's not just a simple app from a feature perspective. It might be a simple app from a feature perspective. But we're trying to build it in such a way that we could scale it out so that I could handle millions of users. We're trying to build it in a way that when I actually deploy it, it can be resilient to things like database failures or connection terminations. And I can automate it and have a very agile based workflow so that I could start simple and I can keep iterating on it in a very quick, fast way and make it better and better. And these patterns, again, they're true for any cloud environment. But if you follow them, they can really help you fall into what I call the pit of success when building your cloud apps. So the first pattern I'm going to walk through is, the first couple of patterns I'll walk through actually kind of apply to any project in general. But I think they're especially true in the cloud. And this is sort of the first pattern here is basically automate everything and make sure that as you're building your solution, you kind of try to eliminate as much manual process along the way. And you set yourself up so that you can have a very repeatable agile workflow as you're doing this type of environment. And kind of what, you know, you often hear this term dev ops. You know, this kind of workflow we want to be able to enable and that successful teams that really use the cloud in a deep way do a good job of enabling is this workflow where I can start with an idea. I can write some code. I can deploy it. I can run it in production and get a whole bunch of feedback on it. You know, people like it. Is it being successful? Are we seeing weird errors? And I can iterate very quickly, make changes, make fixes, add more features, get it back in production in a very quick way and just continue that process. You know, some teams deploy multiple times a day into a live production environment. One of the things that we've done on the Windows Azure side, on the team side over the last or 18 months, we went from a flow of we only shipped every couple months to the point where we were also in the mode where we actually update Windows Azure to the live service at least every two or three days with something. And we try to do major feature releases every two to three weeks. And getting into that cadence really enables you to kind of get immediate customer feedback and build out your business in a key way. The important thing though to be able to do that is that you have an environment that's repeatable, that it's reliable, it's predictable, and you can enable what I call low cycle time, which is from the point you have an idea to the point you get feedback and your customers are using it, you know, is as low as possible. And so the first two patterns or two or three patterns I'm going to walk through is just some of the best practices that we recommend for how you go ahead and do this. So the first thing we're going to talk about here is sort of automation. So a number of people mentioned they have used Azure. If you haven't used Azure, you know, one of the things that you've probably noticed when you first sign up for it, and certainly if you watch any of our demos or any of the overview talks that I've given in the past, is the Windows Azure portal, which is our management console that lets you see all of the resources that are deployed on Azure and provide a really easy way for you to go ahead and create and manage anything inside of the cloud environment. It's a great portal. It's, you know, we're very proud of it. I'm going to spend the rest of the talk telling you about why you shouldn't use it. But that's not entirely true. You do want to use it actually, especially in the beginning when you're just getting started. It's a great way to explore. So if I want to create a virtual machine inside Windows Azure, I can just say new compute virtual machine. I could say, what do you want to name this? NDC quiet. So I can basically just, hey, I'm going to add, there I can choose what I want to run this on. If I'm an MSDN customer, so if you're an MSDN subscriber, you actually get a whole bunch of Azure resources for free, up to $150 a month of resources. And so at a heavy discount. So you go ahead and take advantage of it. I can deploy this virtual machine anywhere in the world. We'll do West Europe. And I can also choose from a variety of images. So I could deploy SQL. I could deploy Windows. I could deploy Linux. Go ahead and create. And I'm done. And in basically four minutes, I'm going to have a virtual machine that I can go ahead and log into. This is one I have earlier. And I can basically log into it. And I have a nice virtual machine here that I'm an admin on that I could basically do anything I want within it. So you can see here. Again, if it's Linux environment, I could SSH in. And hopefully the network God's willing. We'll see a remote desktop shortly pop up. And I basically have full access on this machine. So there we go. So this is kind of as easy as it is to kind of create a new virtual machine. I now an admin on this box. I can install anything I want on it and I'm good to go. And so this portal makes it really easy to do that. Portal also makes it really easy so that if you wanted to, you could go ahead and say, create new website. And I could say, let's go ahead and create the Scott Goo NDC web. I can pick again where in the world I want to run it. Let's do a, no, it's not in the US. Let's do it. Sure. I can use this in the subscription. I can go ahead and create this. And what I'll see here is I'm creating a new website. Again, I can choose anywhere in the world that I want to go ahead and run it. And generally with Windows Azure, you can see where the website takes about six seconds to create. I've now got a nice little website that I can do. And if I wanted to, I could then go ahead, individual studio. We could call this Hello World. If I want to deploy this to that website, I could just go ahead and hit publish and use the UI here to basically say, let's deploy into that newly created website we just did. It's got Goo NDC web, hit OK. And I could basically just walk through hitting next, next, next. And in about six seconds or 20 seconds, I'll basically have a website that is deployed and running in the cloud that I just created. So this hopefully is an example of how easy it is to kind of use manual techniques and use the portal and use Visual Studio in order to very quickly get going. And so again, it's great for learning. It's great to kind of get started and definitely encourage you in the early days as you're kind of exploring Azure and just trying out the features. This is sort of a fantastic way to get started. The problem though is if every person on your team is using this kind of manual process in order to create and get going every time you want to deploy a new project or run it, you're going to start to make mistakes. And so again, this is great for getting started. It's great for spiking out an idea. But if you're going to really work on a production cloud application of any size, and especially if you're doing a team environment, my recommendation is do this once, learn it, and then automate it. And that's true for everything that we're going to do throughout this talk. And the great thing about Azure, and it's true mostly about pretty much every cloud environment, is everything that you can do through the portal, everything that you can do by right clicking inside Visual Studio, you can also do by automating in a completely scripted way. And you could write that script using PowerShell, you could use that script using things like Chef and Puppet, which are open source frameworks. You could also do things, you're just using the Bash command line tool inside a Mac or a Linux environment. We have scripting APIs exposed to all those different environments. And definitely worth checking out as you do things. So let's go ahead and create a new project and just sort of illustrate how that would work. What would you like to call this project? Silence. Silent 2. Okay. Silent 2. So we're going to create another app. It's a simple, low world app here. And what I'm going to do is inside this Silent 2 app, is I'm going to go ahead here and create simple project, or simple folder, I'm going to call Automation. So it's underneath right next to my solution. And I'm going to paste in a couple of simple little PowerShell scripts. And I'm going to post these later so you can go ahead and download them and use them yourself. And we'll walk through exactly what this thing is doing in just a second. So we'll go ahead and actually first let's kick it off. And what these PowerShell scripts are going to do here, so you can see Silent 2, and I have a little PowerShell window here, is one of them is called Create Azure Website Environment. And we'll call this the Silent 2, so NDC Silent 2 environment. I can choose where I want to deploy it in the world. So I do East to West to West to West. And I'm going to specify a SQL database password to use as start. And basically this is going to kick off in an automated way, provisioning for me in overall environment. Let's look at what the code is here while it's doing it. It's going to take about 70 seconds. And what I'm going to do here is just add a solution folder called Automation to my project. I'm going to add to this some existing items, which are those scripts, so that they can be part of my environment and they can actually be checked into my source control system, which we'll talk about in just a second. And what this script does, Simple PowerShell script, basically takes a bunch of parameters or just some defaults, and what it basically does is you can see I turn on verbose. We'll see if it's running here. And it's saying something about the network not being available. I pretended that work. And you can basically see here sort of a set of automation scripts where it's creating a path. It's going to automate for me, creating this website. And so it's using a command called New Azure Website, where I basically pass in the location and the thing there. This is how I can go ahead and create a SQL server. And you'll notice here one of the things I'm doing is actually retrieving my IP address and setting a firewall rule so that my dev machine can actually connect to it. And then what I do is I create what's called a storage account, which I'm going to be able to use for blobs and queues, which we'll walk through a little bit later. And I'm also then configuring as part of my app settings a number of pre-built settings on the solution here. So these are going to override my web.config files. And you'll notice here I'm passing in my SQL database and my storage details. I'm also enabling what's called the CLR profiler and setting up a new relic package so that we can actually do monitoring and diagnostics and telemetry. And then I embed my connection strings as part of this environment as well. And then when it's done, I just restart the web server we just created, output a bunch of stuff, and then basically just tell how long it took to actually run it. And you can see here, let's see if it's actually complete or whether or not it retried. But you can basically see what we did here is it went ahead and created for me all of this kind of environment. And if I go into the portal now, what I will see is a bunch of stuff that was created. So you can see I have my NDC Silent 2 website, which is what we just programmed. It's now running. I didn't have to click anything in the portal. I have a SQL database and somewhere inside here is the database I just created. And I also then have my storage account somewhere inside here as well that we just automated. And the beauty about this is I can effectively automate everything. It took about 90 seconds to create this environment. And every time now anyone on my team wants to create a test environment, they can basically just run the script and know that the exact same environment that I'm using on my dev machine they now have access to as well in their own environment. If I want to on my test servers or my production environment, I say, oh, we got a bad fix. We got to get this thing out quickly. I can go ahead and run this script. And in 90 seconds stand up a completely cloned environment of what my production system looks like that I can deploy bits into and go ahead and run. And the same way that I can go ahead and create this environment, I can also run a little script called deploy. And what this does is, and most of it is verbose because I'm just trying to output what's happening. But basically it's going to do a build on my solution on the command line and then effectively it just kicks off a deployment and deploys it into that web server environment that we just created. So you can see basically in only about 40 lines of PowerShell, most of it comments and logging statements, I can automate both the creation of my site and the deployment of it. And every time I deploy now, I can just go ahead and just say deploy from the command line. And I know that all the steps will happen always the same way in the same order in a completely automated way. And then I can now deploy as much as I want into the cloud environment and not have to worry about missing something or screwing something up or doing something custom on my machine that won't actually work in someone else's or in my production environment. So I'll post these scripts, you can run them yourself. But again, everything I'm going to show throughout the talk here and everything inside Windows Azure, we basically have an API, both as a REST API, a PowerShell script and a command line bash utility that you can run on Linux or Mac in order to automate everything. And so definitely we're checking out once you actually get beyond kind of the early basics of Azure and figure out how you kind of apply in your environment. So pattern two I'm going to talk about is source control. I was talking to someone about the talk and I said, you know, we're going to basically walk through patterns you should use when you use source control. And he said, well, what happens if you don't use source control? And I said, well, okay, the first pattern, sub-pattern is use it. And then here's a couple other things to talk about specifically in terms of how you use it. You know, definitely do recommend using source control for pretty much anything. But especially in the cloud where you're changing things a lot and where you want to be able to react very quickly to issues that are being reported by your customers, source control is really essential. And it's essential not just for your code, but the other thing you really want to make sure you do in any type of services world is take those check-ins, you know, all those automation scripts that I just showed you and version them as part of your actual application solution along with your database scripts and pretty much everything necessary in order to run or scale your environment. So having checked in together with the code, that way when you actually iterate the code, you're changing the automation scripts at the same time. And if you ever need to roll back or you need to make a quick fix, you can sync the code and know that this set of code matches these set of scripts and that everyone on my team is using them. And we can use them in a very agile, repeatable way. And without having to spend lots of time trying to chase down which scripts or did Joe change this setting? He mentioned this, but he's not available. He's on vacation. You got to really make sure that you have everything in one place and it's totally repeatable. A couple other things just to make clear. Don't check in your secrets. Don't check in your passwords. Don't check in specific locations in your scripts. It's much better to actually, not just much better, you should always parameterize your scripts and store your secrets somewhere else. And also as you're kind of designing your source tree, think hard about what kind of branches you want to have and make sure that you optimize it for what I call a DevOps workflow. So what do I mean by that? There's lots of different ways that you can do branching on your projects or set up your source tree. This is kind of a pattern that we see a lot of kind of medium sized teams use where they basically have effectively a master branch. And this basically always maps to the code that's live in production. And so that way if you're ever having an issue with the live app that's running in the cloud, you can always very quickly switch to that branch, look at the code, look at the automation scripts and know that this is always the central source of truth to whatever is deployed and running that your customers is hitting. What we often then see is people actually set up branches underneath that to map to the different life cycles that they're developing. And often what they'll do is they'll have a development branch, which is where the development team checks into and integrates features. If it's a big team, you might have feature branches underneath. If it's a smaller team or you want to make sure that you're iterating and integrating often, you might just sort of stop at the development branch and have everyone check into that. But it scales if you have a couple people that are working on something that's going to take a week, you can just create a sub branch of development and then push it up through it. And then what we often recommend and often see people do is have a staging branch somewhere in between master and development that you use as kind of effectively your final integration testing or final testing before you go live in production. And so you can use different branch strategies, but one of these, you know, the nice thing about this type of approach, and for a small team, you could just have master and development. You don't need to have all these different branches. But the nice thing about this is it gives you a very agile way that you can flow your code from your dev machine into production in a kind of, again, a repeatable way. The other nice thing about having multiple branches is, again, it makes it much easier and having your master or you could have a sub branch called production if you want to snap it, always available, is that it enables you to kind of very quickly, again, react and make changes in an agile way. So if there's a live issue hitting production right now and you need to make a quick fix, you can just go ahead and create a sub branch off of staging or I guess even off of master. Make your hot fix, check it in, and then get it deployed. And you don't have to worry about having a bunch of features that in theory are all done but you're not a thousand percent sure that you're going to try to snap that hot fix into. This again allows you to kind of move off of the live production code, make a very small surgical fix, get it live as quickly as possible, and not have to spend a lot of time integrating and testing things that haven't hit production yet if it's an emergency. This type of model where you have multiple branches, you're working in different branches and you want to sometimes create new branches on the fly. You can use it with any source environment. Sometimes distributed based source control systems work best because you can quickly kind of move between these and they also kind of work great in kind of a distributed team environment. How many people here are using some kind of DVCS solution, either get or mercurial? Great. You can do all the same techniques I'm showing as well with TFS. We actually have teams within the Azure group, some that use centralized TFS, some of which use Git. We use both of them ourselves. Both work perfectly well in this type of environment. One thing that I've actually been playing with, and you'll see kind of be integrated even more going forward inside Visual Studio and with our team foundation service and server, is Git support. One of the things we announced earlier this year is we're kind of adding first class Git support in Visual Studio. For people that haven't tried that before, we'll just go back to our Silent 2 project here. If you want to use Git, you can now go ahead and just say add solution to source control. You can go ahead and say I want to check it in using either TFS source control, which is centralized or Git. What this will do is basically it's using the same Git command line tool in lib.lyb.git2. Oh my God, that's wrong, that you'd use elsewhere. What this has now done is basically added my project to source control using Git. I can go ahead and do a commit. I could say, if I wanted to, I could say initial check in, do a quick commit. Basically I just went ahead and checked in code. If I make a change, if I change this to say something else, I could do that. I can highlight what's changed. One of the things that's kind of nice is there's full diffing support with the VS tools. You can forget here. I can actually see the changes that I'm making and easily check them in. The nice thing about this also is if I want to ever make a branch, I could basically do that in an easy way. Let's say I realize, oh my gosh, we've got a bad problem that we need to fix. I could go ahead and create a new branch that I want to work with. I could very easily make a change to it. Create a new branch, we'll call this hotfix1. I now have a hotfix. I can go ahead and say this text should be different. Quickly go ahead and check this in. One of the things that's nice is as I switch between the branches, you'll notice here my code and my solution explorer will automatically change as well. It's a simple example of how quickly I can create a branch, work on something, flip back and forth between my development and my master, make a change, go ahead, use the automation scripts that are all checked in as part of my source control in order to push a live update or create an environment in order to do that testing in a very kind of agile way. This isn't the only way you can do it. You can use material, you can use TFS, you can write your scripts in whatever approach you want, but having these types of tools available are going to make you very repeatable, very agile, be able to respond quickly and have a lot of flexibility. If you ultimately want to check this in to kind of a team environment, the Git tools that we shipped inside VS do allow you to point to a Git repo, you can go to GitHub. One of the things that we're doing is actually now support as part of the team foundation service that we run and will ultimately ship as part of TFS server as well is adding Git repo support to that so that you can still use all the same TFS capabilities in terms of project and work item and bug tracking, but integrate Git as part of that as well. Some things to think about in terms of source control, but again the key things here are check in your scripts as part of your solution, parameterize everything, don't check in your secrets and then think hard about your branching strategy and really measure yourself on how quickly can you go ahead and make a change, get it live in a very safe, predictable way. Anytime that you think, gosh, I'm scared to make this change or we need to spend a day or two just doing kind of manual testing on it, pause and ask yourselves what do we need to do process wise, what do we need to do test wise in order to make it so that we could make that change in minutes or at least within an hour and do it in a very fast way that you feel comfortable with. Last sort of process thing I'll talk about before we dive into more code is another pattern here continuous integration and continuous delivery that people have probably heard the buzzword around. How many people are using a CI solution? How many people know that they should be using a CI solution? Okay. How many people are doing continuous delivery? That's a little bit more kind of new. Cool. The number of people you're doing here. How many people have no idea what I'm talking about? Okay. You're being, you're not being brave enough. I'm sure someone here is wondering what in the heck is continuous integration delivery? Well, at a high level the nice thing about continuous integration delivery done right is it enables a deployment pipeline so that you can integrate with your source trees, you can integrate with your automation environment and enable it so that every time someone does a check in, you can in a repeatable automated way go ahead and do a build, run your test against it and with continuous delivery you can go one step further and actually take those automation scripts and actually deploy it either by having someone push a button or even a completely manual or completely automated way as soon as the build tests pass into an environment that you can actually do more in depth testing with. And hopefully what you've seen with the automation that I've shown is automating everything inside Azure is really easy. Because it's running in the cloud, you're not having to build servers in order to actually or buy servers in order to actually do that. And the beauty about integrating the cloud with a continuous integration or delivery environment is you can now basically instead of having to wait for a server to be available to do your testing on, you can actually on every build that you do go ahead and actually spin up a test environment inside Azure, run acceptance tests or more in depth tests against it, then when you're done just tear it down. And if you only ran that server for say two hours or ten hours or a day, the amount of money that you actually would need to spend in order to pay for that because you're only paying for what you're using, you're only paying for the hours that that machine is actually running. And I can't do the conversion in my head. But in general, like a website, the website environment that I'm running right now basically costs one US cent per hour effectively. Actually, the one I just deployed will be free. But if I go to tear up, it's 1.6 cents per hour, which I don't know what it translates into in origin currency, but it's not much. And basically, it's less than, if you ran this for a month and you ran the environment effectively for only an hour at a time, it would probably cost less than a latte that you bought at Starbucks in order to actually have that environment used for your kind of environment. So it ends up being very cost effective, fully automated. And again, if you haven't used continuous integration and delivery before, it's definitely worth checking out. And generally what I recommend going back from the branching strategies is have at least your development and your staging environments be automated from a deployment perspective. So every time you check in, if your build tests pass, deploy it into some environment. Then you can run your full acceptance test, or you can have people on the team go ahead and check. If you want to be really bold, you could say every time we actually integrate into the master branch, also automatically deploy the live production site. That's kind of the nirvana that everyone knows that they should aspire towards. I'll be candid, most teams don't do that even within Microsoft. Just because sometimes it's nice to have some human being just sort of say, yep, we really want to push it live in the middle of the afternoon versus, well, let's actually wait until early morning or some point where all the dev team is available for us to go live. So often people will have a last minute manual check or at least push the OK button before it goes live in production. But there's nothing that can prevent you from actually having your entire dev environment and your entire test environment be completely automated so that all the developer needs to do is effectively just push their source into the main tree or in one of the branches in the main tree. And you can basically build it, run your unit tests, deploy it, run your acceptance tests, completely automated, and have as many developers on the team going ahead and doing that 24.7, very, very cost effectively. There's lots of solutions you can do to enable this. There's a bunch of great talks throughout the conference about integration and delivery. I can't do justice here, but hopefully I just wet your appetite. One thing that we're also working on ourselves, so there's things like TeamCity and other, Hudson and other environments that you can use in order to do CI and CD. One of the things though that we're also working on is part of our team foundation service, which is free up to five people, and you can sign up and actually play with it today, is actually trying to make it really great to do this type of continuous integration and continuous delivery without you having to set up anything. So it runs as a service, it actually runs on Azure, it supports both Git and TFS, and it now has an elastic build service so that you don't actually have to have build servers lying around. Instead, every time you push your code in, it can automatically kick off a build using servers that we maintain, and we don't charge you as long as you do a certain number of builds, then you can have reserved build servers if you want to pay a little extra. And we basically do continuous integration, we can deploy to Azure. They also just recently added load testing support, so once it's actually in an environment, you could start throwing load at it in order to measure performance and stability, and they just recently added some team room collaboration and some more agile project management capability. So if you're looking for kind of a turnkey solution, that's one you can also go ahead and look at. So now we talked a little bit of process, let's now drill in more into code, and I'm going to walk through a couple of best practices here, both on the website as well as with enterprise integration and then data throughout the rest of this talk. So let's start with web. How many of you here are doing web development or building apps? Great. A lot of these best practices apply both for web as well as for custom mobile back ends if you're using, say, ASP.NET web API, you can apply these as well. And at a high level, some of these ones that I kind of listed here from a best practice perspective that I kind of recommend, the first two kind of just are pretty obvious and then we'll drill into some of the more detailed ones a little bit later. But one is, you know, wherever possible, be stateless on your web tier. In other words, try not to use session state, try not to have anything that needs to be stored in the web server in a stateful way. Try to have it be as stateless as possible. There's a couple of reasons for that. One is if it's stateless and you put those machines behind a load balancer, it makes it really easy for you to go ahead and just keep adding machines as you need capacity. And it also makes it really easy for you to shrink machines or turn off machines as you don't need capacity. In an environment where you're only paying for what you use, that ability not only to expand but also to shrink your capacity based on load translates into huge savings. It also makes it architecturally much simpler to scale out your solution. So if possible, avoid session state since that does add some state. If you do need to use session state, don't store it in a database. We have a nice cache provider that you can use on Azure that we recommend instead. And that actually scales out and is much more cost effective and much better. Recommend using a CDN. For people who don't know what a CDN is, it's a content delivery network. This basically allows you to edge cache your JavaScript as well as your images so that if your customers are accessing your website, they don't always have to hit your web server. Instead, they can hit a cache location somewhere closer to them. In particular, if you are reaching a broad audience, that can help and just speeds up the overall load time of the site. And then this last one is something that, I'm curious to see how many people here are using the.NET 4.5 async support. People know that there's async support. Cool. It's really cool. Definitely recommend using it, both for your on-premise, this is based applications. So if you're running existing Windows servers inside your organization, but especially also in the cloud. And it allows you to kind of avoid making any blocking calls within your solution and really enables you to scale out in a much richer way. So for people that haven't seen it or they've heard about it, this is sort of a simple example and we'll walk through this fix it code in just a second of where I'm using async and some of the benefits that it provides. So basically you can see now with the latest version of ASP.NBC, web API and web forms, we have full async support. You can effectively just go ahead and mark a method as async. Then you typically return a task of T. And then I can go ahead and every time I make a call to an async API, I can effectively say await on it. And what this does under the covers is the compiler will then automatically generate the appropriate async code so that as I'm waiting for this fix it repository fine task by ID async method to go hit the database, ASP.net can unwind the worker thread and use that thread to process another request. And the benefit there is instead of, you know, let's say the server has 10 worker threads, instead of having a lot of them blocked waiting on database calls or remote network calls, it can process a lot more requests much more efficiently. And you could do this in the past even with ASP.net one because it did have async APIs, but it was frankly kind of a nightmare to write that code and very error prone because you had to write a lot of async code in order to handle all the error conditions. What we've done in.net four or five has made it really easy. So just directly within C sharp or VB, you can use these keywords in order to express the same intent and really scale out your app in a great way. A lot of people, you know, often talk about Node.js as an async based way in order to build server apps. We support Node.js also in Azure. The nice thing about the async support that we now have inside.net is we do all the same things. We provide all that same capability. But I think from an API perspective, especially if you're coming from more of a procedural background, it's a little bit cleaner. You get full intelligence and full debugging. And then the benefit is the actual code that's running is also running through the standard CLR Just-in-Time Compiler. So you're running very, very optimized code on the server so that when your code is running, it's actually going to be much faster than, say, an interpretive environment. One thing that's cool that I'm taking advantage of in this app is we shipped as part of web forms, MBC and Web API async support for the web server, but our data libraries didn't support it yet. You could call web services, you could call sockets or do file system IO async. But the most common pattern for most people building web apps is to hit a database of some shape or form. We're adding into entity framework six async support. And this is now available in preview. And the final release will be out in a few months. And what this means now is in my fixit repository class that I've defined here, you'll notice that I'm able to access an entity framework context. This is just a standard code first database context. I can then have my repository classes also be async. And then I can go ahead and call now my database and insert and retrieve things in a completely async way. And this now means both my data access library and my web tier can unwind the worker threads and run code in a super efficient way. But anytime I hit my database, I'm not blocking and I can actually return things again in scale much better. And what's cool is this works not just for simple finders or inserts and deletes. It actually composes with link queries as well. And so this is an example inside the code we'll walk through in just a second where I'm actually writing a complex link query and using where clause is in order buys. And what you'll notice here is this whole method is async so that this whole complex query is going to be passed to the SQL database. The thread gets reused for another request. When the SQL database returns it, we can re-queue the thread, continue execution from the exact same place logically in the code that it left off and continue running. And now you can basically not block ever on the server and have an app that will scale better than pretty much any framework out there on the server in a really clean way using the C-sharp or VB or other.NET language that you already know. So I'm using this heavily within the application and we'll walk that code in just a second. Other things here in terms of what I'm using inside this web app just to kind of explain some basics. I'm taking advantage of a feature here of Azure we call websites. This is basically a way that you can go ahead and host a web app inside Azure without having to host and run your own virtual machine in order to do it. And so we actually provide all of the mechanisms necessary to basically run that website inside Azure and we'll do the hosting and the scale out and the recovery for you automatically. It works with ASP.NET, it works with Node.js, PHP and Python and it enables you to kind of very quickly deploy in seconds. And so you can make changes and quickly refresh them usually in a matter of less than 10 seconds from the point you hit deploy to the point that it's live in production. Now what's great is you can deploy on a free environment and then scale up as you need to. And basically the way this works, it's simple. You saw me earlier create the website and then just deploy to it. Under the covers behind the scenes, it's kind of a complex environment. It's really kind of building and providing for you a lot of features that if you're using purely a virtual machine in order to set up and manage IAS, you'd actually have to build yourself. And this diagram here on the right is sort of an example of what this environment looks like. Basically when you show up and you say I want to run this website, you can choose how many machines you want to run it on. So I can say I want to run on one virtual machine or I want to run on two virtual machines. And it'll basically stand it up and create it for you. And then what the service, the website Azure services also doing is provides a deployment endpoint so that when you say I want to deploy my app, whether it's through VS or whether it's through an automation script, it'll automatically deploy onto those machines the bits that you actually go ahead and produce. And so it does all of the laying down the bits, setting them up, making sure IAS is ready in order to use them. And then when a customer shows up and types in the URL, they hit those machines. Now the cool thing also about the website services, they don't hit the virtual machine directly. The Windows Azure website runs a pool of what we call load balancers that are using a level layer seven application request router load balancer, which again you can run yourself. But the beauty is it's set up for you automatically and they'll route that request to the appropriate machine. If a lot of requests come in at the same time, they'll automatically route them to all the different virtual machines and it uses a fairly smart heuristic so that it sends requests both based on affinity as well as based on actual the queue depth inside IAS as well as the CPU on the virtual machine. And so basically we can be very smart in terms of the load traffic that's actually distributed and all that's built in. And then the other thing that's nice about it is if a virtual machine goes down, it'll automatically pull it from the rotation so no more traffic goes to it, spin up a new instance and then automatically start directing traffic to it. And so all this kind of mechanics happen behind the scenes, all you need to do is basically just say create me a website in one line of PowerShell or just go in the portal and create site and you get to take advantage of all this. And that's what we're doing within the app. So let's walk through the code and look at this real quick. So basically this is my fix it app here and you can see it's just a standard web project. I can run it. I've got a logging library and a data access library that we'll look at. And so when I hit control at five here you can see this is running in my local dev environment so I can do everything offline if I want to. In terms of kind of how it's implemented it's using ASP.NET NBC. So let's just go back here and we'll look at logging and other things in part two. But you can see basically I've got controllers. I got a home controller, a task controller and a dashboard. The dashboard is gives me kind of crud support. And again you can see pretty standard action methods that are exposed here. They're all doing async. And so you can kind of see a simple example here where I have details get passed in. It calls a repository, returns hp.found. If it didn't find it or basically just renders the content there. One thing you'll notice is I'm passing in as a constructor argument to all of my repositories and all of my controllers a few parameters. So my controllers all get an itask repository. And if you go and look at the repository you'll see it gets passed in a logger interface that it uses as it's doing its data access. And basically what I'm taking advantage of is dependency injection. And specifically the auto fact dependency library. And so there's a couple different ways you could do dependency injection. This is a nice framework so instead of me manually passing in these things what I did inside this code is take advantage of auto fact. And all I need to do is say every time you see an I fix it task repository in a controller or an I logger or an I photo service just pass in this specific instance into it. And so basically in just sort of these six lines of code I can now very cleanly inside any of my classes that I use inside my framework just go ahead and get my dependencies passed in. Makes it a lot easier for me to go ahead and test. And that basically ends up being kind of my data library kind of a nutshell. And again it's running inside Azure. So if I go ahead and click on this. This is a Europe instance here. I can drill into this particular app inside Azure. And you'll notice built into Azure is a dashboard so I can see how many requests that was probably from last night and that was when I was running it just a few minutes ago that I actually hit on it. If I want to scale it I can click the scale tab or again I can set a power shell command so everything I'm doing here I can also go ahead and run. And if I wanted to say hey let's deploy this on six medium sized virtual machines all you need to do is hit save and it will auto scale now this app in a matter of about 10 seconds to five more virtual machines that are each about three and a half gigs of RAM and my app is now running on it. So basically it was just a few commands or through the portal I can very easily deploy this app and then scale it up or scale it down. And that whole environment that I walk through where I have load balancers automatically in front of it I'm doing automatic protection in case that app ever goes down and I'm running it in a completely async way all just works. So you can do this pretty much with any ASP.NET app and take advantage of it really easily. One last thing I'll just mention real quick is if you click the configure tab you'll notice here a bunch of app settings and connection strings that are available and this is basically a way when I ran that script up front one of the things I briefly touched on is how you can go ahead and script these as part of the environment. So when I created this environment as an example here I basically specified that I want to use these settings. Some of them are never changing a few of them like my storage account name are dynamically created elsewhere in the script and passed in as arguments. One nice thing about this model here is it allows me as a developer I can basically have dev settings inside my web.config file that I use. So I just do app settings or get connection string from my config file and then at runtime this allows me to override the settings that are in the web.config file with production based environment. So you'll notice here from my dev environment here I have a local DB data source checked into my web.config and so all the developers will just use a local database on the machine as they're doing development. And then at runtime when I create my environment in an automated way that script created a database for me and it automatically set a production connection string on that web server and now when my app runs in this environment it will automatically connect to the production database instead of my local DB. And so this provides a really nice way that you can override in an automated way and it makes it really easy so you're not checking in secrets into your source code so you don't actually have to modify the web.config as part of your build process. Instead you can use this app settings and connection strings model to basically override these values at runtime and have only a set of approved folks know what the production settings actually are. So again the scripts will show you how to do that. So we talked about some web things, let's now talk about security and then we'll talk about data. And so what I want to talk a little bit about is this pattern here which is single sign on. And one question people often ask me is okay I'm building primarily apps for the employees within my company, how do I host it in the cloud and still allow them to use the same security model that they already know and use in their on-premises environment when they hit my app that's running inside the firewall. And one of the ways that we're kind of doing to enable this and you'll see some announcements come out in the next couple weeks is through something we call Windows Azure Active Directory. And this is basically providing Active Directory in the cloud. It integrates with an on-premises environment, enables single sign on within all your apps and it does it in a way that's open standard. So I can use SAML, I can use OAuth and I can use OAuth 2 in order to connect to it and integrate within my applications. And the beauty is we're making it really easy in order to actually set up. And so you can kind of just build a diagram here. Imagine you have an on-premises Windows server environment where you're using Active Directory to have your employees sign on. And so you kind of make this work just like today. What we're allowing you to do with Azure is create a directory in the cloud and it's a free feature so you can do it without having to pay anything. And that directory can be used also to sign on. And you can have that directory only have basically be disconnected so you can put anyone you want into it. Or the cool thing is you can connect it to your on-premises Active Directory at which point all of the users that could log on on-premise can now also authenticate using Azure without you having to open up a firewall, without you having to actually deploy any custom new servers. You can leverage all the existing Active Directory environment that you know and use today. And at that point then your mobile devices and your web apps can authenticate in the cloud and you could basically have your app that you hosted in the cloud, including your enterprise internal-facing apps, now have enterprise single sign on. You can also use this for third-party apps. So for example, if you're using Salesforce.com or Google Apps or Office 365, you can use this directory in the cloud in order to enable single sign on with them as well, all in a secure way. And the beauty is anytime a new user gets created into your organization or anytime a password changes, they just use the same mechanism they use today on-premise and it will automatically flow and apply immediately in the cloud as well. So it makes it very secure. Doing this is pretty easy. Again, you can do it through PowerShell. I'm going to do it through the portal just to kind of illustrate the concepts. Basically you just go inside Azure, you click on Active Directory. If you don't already have a directory, there's a little button here called Create One. Right now you can only create one directory and you can't delete it. So think carefully about what you name it. I named it Scott Guthrie, which is actually very confusing because Scott Guthrie is now both a directory as well as a user. The ability to create multiple directories is coming, but right now it's only one per account. And basically, within this directory, I can add users. So we basically have full support for creating and managing users within this environment. So if I wanted to, I could go ahead and create Tom and add this and I can give username last names, pick the roles, and it will go ahead and create a new account for them in the system. And once I do that, then they can go ahead and log in using this cloud directory. What's cool of those, I can also click this directory integration tab. And if I enable this and then download a tool that there's a link for, I can also then sync my existing on-premises active directory that I'm already using inside my organization with this cloud, at which point all the users in my organization will show up in this directory as well. And at that point, then, I now have a lot more users and I can do single sign-on within all my apps in order to integrate them. And doing this is really easy. We just shipped a tool actually last week that you can download. Again, it's a free tool and the Windows Azure Active Directory itself is free to anyone. You download the tool, you click Next, you enter in your Azure account details, you click Next, you enter in a domain user account that's on your corporate network. So this is your existing on-premise network. You click Next, you click this enable password sync if you want to go ahead and hash your passwords and store a hash version in the clouds. We never know what your passwords are. It's a one-way hash. Alternatively, if you never want to send any passwords, including hashes, you can also use ADFS and set it up. So a few extra steps there, but that also allows you to use the cloud directory as well. But for this simple model, just go ahead and click the hash. Click Wait a few minutes and you're done. And at that point, then, if you run this on a domain controller, just one domain controller inside your organization, it can be Windows Server 2003 or higher. All your users are basically in the cloud and you can now do single sign-on from within any web or mobile application. Again, using SAML, OAuth, or WSFed as an API head. This makes it really easy in order to actually integrate enterprise security in this model. So let's go ahead and walk through how you do that. It's really simple. Basically, you can go now into the portal and you can create an application. Again, you can also do this through the command line. And all you need to do is just say, what's the app I want to run? So I can call it fixit web 2. I can enable single sign-on. I can also give directory access so you could read or write properties in the directory on users so you could see what their phone number is, whether they're in the office when they last logged on, in a kind of graph REST API way. So if you're ever familiar with Facebook, think of this as like an enterprise Facebook graph where I can just say, just do sign-on. And all I need to do then is basically paste in the URL of where my app is deployed and I give it effectively a URI secret that embeds as part of it. And then you hit OK. And at that point, I can have any number of apps deployed. This is the one that I have inside North Europe. And basically, I just paste in this key into my web.config file. And this works for any app in the tenant so you don't have to configure it. And at that point, what I can do inside the new version of ASP.net that's coming out in about a week and a half. So now, let's go ahead and do that in room numberconf
 Thanks everyone for coming to NDC.  This is my second time here and really excited to be back and want to thank everyone for  coming out this week to the conference.  It looks like some great speakers and great content throughout the week.  My name is Scott Guthrie.  I work at Microsoft on a couple different things, one of which is Windows Azure.  What I'm going to do is spend this talk and the next talk kind of walking through a new  talk that I've never done before, so I'm pretty excited to give it, which is basically called  Building Real World Apps with Windows Azure.  It's going to be kind of a patterns-based approach and I'll kind of walk through exactly  what I mean just in the next couple slides.  That walks through kind of how you build real world cloud-based solutions and the patterns  are going to talk about apply to any cloud environment.  You can use them with Amazon, you can use them with Google, although I'd really like  it if you use them with us.  The demos I'm going to walk through are going to be using.NET and Visual Studio and using  Windows Azure to kind of show off how these concepts work and hopefully make them really  real.  How many people here have used Windows Azure?  Okay, good.  A lot of people have.  A few people haven't.  If you haven't, don't freak out.  I'm going to provide enough context hopefully throughout the talk that, oh yeah, two bottles  of water.  Thank you.  Even if you don't know what Windows Azure is, hopefully you know what it is at a high  level, but if you don't know it from a practicality perspective, you'll still be able to kind  of benefit and pick up a lot of things here.  In terms of, so I'm going to spend 115 slides walking through patterns of cloud computing.  I thought I'd just kick it off though first by walking through, first, what are some of  the benefits that cloud computing gives you?  Every time you want to learn new things, you might ask yourself, why am I learning it?  I think ultimately cloud computing is exciting for a number of reasons.  One of the reasons is as developers, it just lets us do more.  It lets you reach your customers in a deeper way.  You can build more engaging experiences.  You can do things like mobile.  You can use things like analytics to have a much richer customer experience.  You can reach other markets with cloud computing because there's data centers around the world.  You can very easily expand your business into new geographies.  You can deliver things that just weren't possible today.  We're going to build a simple solution today and walk through some of the concepts of it.  It looks pretty small.  It is a relatively small app.  The nice thing about the way we're going to build it is if we wanted to build it so that  we stored hundreds of terabytes of content with it, we could.  If we wanted to build it so that we could run it across a thousand servers, we're going  to architect it such that we could.  It lets us approach problems that previously were just not practical and are now real.  It's going to do it in a way that's cost effective.  The app I'm going to build, you can basically develop and test it completely for free.  Everything we're going to build, you could do it no cost whatsoever.  The nice thing about cloud computing and Windows Azure is you pay only for what you use.  As your app grows, as the amount of storage grows from a couple megabytes to a couple  gigabytes to a couple terabytes, you're only paying for what you're actually using and  you're not having to preallocate a lot of resources, which also, in addition to the  technology from a business model perspective, again, enables you to kind of build apps that  otherwise you might have a hard time getting your company to approve.  Hopefully, you'll see at the end of the day, it's a really rich, flexible, and ultimately  very agile environment that as developers ends up being fun.  What I'm going to try to do today is walk through what I'm calling common cloud patterns  that will help you be successful targeting this environment.  Specifically, I'm going to walk through a simple app.  I'm calling it Fixit, which is a very simple app, but it shows off a number of these patterns.  It shows off data access.  It shows off security, including enterprise, single sign-on with Active Directory.  It shows off queuing.  It shows off, we'll talk about caching, and we'll talk about telemetry and monitoring  and logging and a whole bunch more.  Specifically, here are the 13 concrete patterns we'll walk through, both this first talk and  then the second talk.  Using this code as sort of an example, and hopefully, you'll arm you with kind of the  knowledge so that if you took the slides, took the code, you could go off and you could  build pretty much any type of web or mobile-based application using these patterns and know  that when you deploy it and run it, you'll be successful and hopefully have a really  agile development environment that lets you kind of reach and build these types of new  solutions.  These are kind of the patterns we'll walk through.  We're going a lot more depth on each of them throughout, and basically we're going to use  kind of explain the concept and walk through code and hopefully make it real for each of  these.  A quick, simple demo of this app that we're going to walk through.  Again, it's a pretty small app.  It's called Fixit, and I'm not sure if Fixit translates well in Norwegian, but basically  think of it as a ticketing system where you can go and you can say, I need something fixed  and upload a ticket, and then someone can go ahead and process it and do something with  it.  So it's not a very complicated app, but the idea is you could go to it, you could log  in using a forms authentication and a database, or what I've also wired up is supports that  I can do enterprise single sign-on with Active Directory.  So what I just did was redirect it to my company's portal, or sorry, company single sign-on.  I'll walk through how you do that yourself, I can spell Microsoft correctly.  And so basically I just logged in using my company security model.  I can say, pick up room.  My room is a mess.  I'm going to sign it to myself.  I'm David, but let's see.  Trash, there we go.  If I can upload a picture of what I want to get fixed, I can go ahead.  I've uploaded it.  I could create more tickets if I wanted to.  Clean close.  Please they smell.  Signed it also to Scott.  Again I'm logged in as David.  And so forth.  So that's the progress of the items that I've done.  You can see I have a few, one that I've been working on last night.  And then basically I'm just going to log off out of this application.  And I'm going to log back in this time as me using the integrated off.  So no single sign-on here.  When I log in now I can see what issues are assigned to me.  You can see David assigned to me.  I need to clean the close and I can see a picture of my dirty close.  And I could say they do.  Market fixed to close it out.  So again, very simple application.  Not a huge in-depth app.  But one that is rich, hopefully you can look at and say, yeah, I could build that.  And what I'm going to do though is try to show you then how you could build this simple  app but incorporate all these patterns as part of it.  So that it's not just a simple app from a feature perspective.  It might be a simple app from a feature perspective.  But we're trying to build it in such a way that we could scale it out so that I could  handle millions of users.  We're trying to build it in a way that when I actually deploy it, it can be resilient to  things like database failures or connection terminations.  And I can automate it and have a very agile based workflow so that I could start simple  and I can keep iterating on it in a very quick, fast way and make it better and better.  And these patterns, again, they're true for any cloud environment.  But if you follow them, they can really help you fall into what I call the pit of success  when building your cloud apps.  So the first pattern I'm going to walk through is, the first couple of patterns I'll walk  through actually kind of apply to any project in general.  But I think they're especially true in the cloud.  And this is sort of the first pattern here is basically automate everything and make  sure that as you're building your solution, you kind of try to eliminate as much manual  process along the way.  And you set yourself up so that you can have a very repeatable agile workflow as you're  doing this type of environment.  And kind of what, you know, you often hear this term dev ops.  You know, this kind of workflow we want to be able to enable and that successful teams  that really use the cloud in a deep way do a good job of enabling is this workflow where  I can start with an idea.  I can write some code.  I can deploy it.  I can run it in production and get a whole bunch of feedback on it.  You know, people like it.  Is it being successful?  Are we seeing weird errors?  And I can iterate very quickly, make changes, make fixes, add more features, get it back  in production in a very quick way and just continue that process.  You know, some teams deploy multiple times a day into a live production environment.  One of the things that we've done on the Windows Azure side, on the team side over the last  or 18 months, we went from a flow of we only shipped every couple months to the point where  we were also in the mode where we actually update Windows Azure to the live service at  least every two or three days with something.  And we try to do major feature releases every two to three weeks.  And getting into that cadence really enables you to kind of get immediate customer feedback  and build out your business in a key way.  The important thing though to be able to do that is that you have an environment that's  repeatable, that it's reliable, it's predictable, and you can enable what I call low cycle time,  which is from the point you have an idea to the point you get feedback and your customers  are using it, you know, is as low as possible.  And so the first two patterns or two or three patterns I'm going to walk through is just  some of the best practices that we recommend for how you go ahead and do this.  So the first thing we're going to talk about here is sort of automation.  So a number of people mentioned they have used Azure.  If you haven't used Azure, you know, one of the things that you've probably noticed when  you first sign up for it, and certainly if you watch any of our demos or any of the overview  talks that I've given in the past, is the Windows Azure portal, which is our management  console that lets you see all of the resources that are deployed on Azure and provide a really  easy way for you to go ahead and create and manage anything inside of the cloud environment.  It's a great portal.  It's, you know, we're very proud of it.  I'm going to spend the rest of the talk telling you about why you shouldn't use it.  But that's not entirely true.  You do want to use it actually, especially in the beginning when you're just getting  started.  It's a great way to explore.  So if I want to create a virtual machine inside Windows Azure, I can just say new compute  virtual machine.  I could say, what do you want to name this?  NDC quiet.  So I can basically just, hey, I'm going to add, there I can choose what I want to run  this on.  If I'm an MSDN customer, so if you're an MSDN subscriber, you actually get a whole bunch  of Azure resources for free, up to $150 a month of resources.  And so at a heavy discount.  So you go ahead and take advantage of it.  I can deploy this virtual machine anywhere in the world.  We'll do West Europe.  And I can also choose from a variety of images.  So I could deploy SQL.  I could deploy Windows.  I could deploy Linux.  Go ahead and create.  And I'm done.  And in basically four minutes, I'm going to have a virtual machine that I can go ahead  and log into.  This is one I have earlier.  And I can basically log into it.  And I have a nice virtual machine here that I'm an admin on that I could basically do  anything I want within it.  So you can see here.  Again, if it's Linux environment, I could SSH in.  And hopefully the network God's willing.  We'll see a remote desktop shortly pop up.  And I basically have full access on this machine.  So there we go.  So this is kind of as easy as it is to kind of create a new virtual machine.  I now an admin on this box.  I can install anything I want on it and I'm good to go.  And so this portal makes it really easy to do that.  Portal also makes it really easy so that if you wanted to, you could go ahead and say,  create new website.  And I could say, let's go ahead and create the Scott Goo NDC web.  I can pick again where in the world I want to run it.  Let's do a, no, it's not in the US.  Let's do it.  Sure.  I can use this in the subscription.  I can go ahead and create this.  And what I'll see here is I'm creating a new website.  Again, I can choose anywhere in the world that I want to go ahead and run it.  And generally with Windows Azure, you can see where the website takes about six seconds  to create.  I've now got a nice little website that I can do.  And if I wanted to, I could then go ahead, individual studio.  We could call this Hello World.  If I want to deploy this to that website, I could just go ahead and hit publish and  use the UI here to basically say, let's deploy into that newly created website we just did.  It's got Goo NDC web, hit OK.  And I could basically just walk through hitting next, next, next.  And in about six seconds or 20 seconds, I'll basically have a website that is deployed and  running in the cloud that I just created.  So this hopefully is an example of how easy it is to kind of use manual techniques and  use the portal and use Visual Studio in order to very quickly get going.  And so again, it's great for learning.  It's great to kind of get started and definitely encourage you in the early days as you're  kind of exploring Azure and just trying out the features.  This is sort of a fantastic way to get started.  The problem though is if every person on your team is using this kind of manual process  in order to create and get going every time you want to deploy a new project or run it,  you're going to start to make mistakes.  And so again, this is great for getting started.  It's great for spiking out an idea.  But if you're going to really work on a production cloud application of any size, and especially  if you're doing a team environment, my recommendation is do this once, learn it, and then automate  it.  And that's true for everything that we're going to do throughout this talk.  And the great thing about Azure, and it's true mostly about pretty much every cloud environment,  is everything that you can do through the portal, everything that you can do by right  clicking inside Visual Studio, you can also do by automating in a completely scripted way.  And you could write that script using PowerShell, you could use that script using things like  Chef and Puppet, which are open source frameworks.  You could also do things, you're just using the Bash command line tool inside a Mac or  a Linux environment.  We have scripting APIs exposed to all those different environments.  And definitely worth checking out as you do things.  So let's go ahead and create a new project and just sort of illustrate how that would  work.  What would you like to call this project?  Silence.  Silent 2.  Okay.  Silent 2.  So we're going to create another app.  It's a simple, low world app here.  And what I'm going to do is inside this Silent 2 app, is I'm going to go ahead here and create  simple project, or simple folder, I'm going to call Automation.  So it's underneath right next to my solution.  And I'm going to paste in a couple of simple little PowerShell scripts.  And I'm going to post these later so you can go ahead and download them and use them yourself.  And we'll walk through exactly what this thing is doing in just a second.  So we'll go ahead and actually first let's kick it off.  And what these PowerShell scripts are going to do here, so you can see Silent 2, and I  have a little PowerShell window here, is one of them is called Create Azure Website Environment.  And we'll call this the Silent 2, so NDC Silent 2 environment.  I can choose where I want to deploy it in the world.  So I do East to West to West to West.  And I'm going to specify a SQL database password to use as start.  And basically this is going to kick off in an automated way, provisioning for me in overall  environment.  Let's look at what the code is here while it's doing it.  It's going to take about 70 seconds.  And what I'm going to do here is just add a solution folder called Automation to my  project.  I'm going to add to this some existing items, which are those scripts, so that they can be  part of my environment and they can actually be checked into my source control system,  which we'll talk about in just a second.  And what this script does, Simple PowerShell script, basically takes a bunch of parameters  or just some defaults, and what it basically does is you can see I turn on verbose.  We'll see if it's running here.  And it's saying something about the network not being available.  I pretended that work.  And you can basically see here sort of a set of automation scripts where it's creating  a path.  It's going to automate for me, creating this website.  And so it's using a command called New Azure Website, where I basically pass in the location  and the thing there.  This is how I can go ahead and create a SQL server.  And you'll notice here one of the things I'm doing is actually retrieving my IP address  and setting a firewall rule so that my dev machine can actually connect to it.  And then what I do is I create what's called a storage account, which I'm going to be  able to use for blobs and queues, which we'll walk through a little bit later.  And I'm also then configuring as part of my app settings a number of pre-built settings  on the solution here.  So these are going to override my web.config files.  And you'll notice here I'm passing in my SQL database and my storage details.  I'm also enabling what's called the CLR profiler and setting up a new relic package so that  we can actually do monitoring and diagnostics and telemetry.  And then I embed my connection strings as part of this environment as well.  And then when it's done, I just restart the web server we just created, output a bunch  of stuff, and then basically just tell how long it took to actually run it.  And you can see here, let's see if it's actually complete or whether or not it retried.  But you can basically see what we did here is it went ahead and created for me all of  this kind of environment.  And if I go into the portal now, what I will see is a bunch of stuff that was created.  So you can see I have my NDC Silent 2 website, which is what we just programmed.  It's now running.  I didn't have to click anything in the portal.  I have a SQL database and somewhere inside here is the database I just created.  And I also then have my storage account somewhere inside here as well that we just automated.  And the beauty about this is I can effectively automate everything.  It took about 90 seconds to create this environment.  And every time now anyone on my team wants to create a test environment, they can basically  just run the script and know that the exact same environment that I'm using on my dev machine  they now have access to as well in their own environment.  If I want to on my test servers or my production environment, I say, oh, we got a bad fix.  We got to get this thing out quickly.  I can go ahead and run this script.  And in 90 seconds stand up a completely cloned environment of what my production system looks  like that I can deploy bits into and go ahead and run.  And the same way that I can go ahead and create this environment, I can also run a little  script called deploy.  And what this does is, and most of it is verbose because I'm just trying to output what's happening.  But basically it's going to do a build on my solution on the command line and then effectively  it just kicks off a deployment and deploys it into that web server environment that we  just created.  So you can see basically in only about 40 lines of PowerShell, most of it comments and  logging statements, I can automate both the creation of my site and the deployment of it.  And every time I deploy now, I can just go ahead and just say deploy from the command  line.  And I know that all the steps will happen always the same way in the same order in a  completely automated way.  And then I can now deploy as much as I want into the cloud environment and not have to  worry about missing something or screwing something up or doing something custom on  my machine that won't actually work in someone else's or in my production environment.  So I'll post these scripts, you can run them yourself.  But again, everything I'm going to show throughout the talk here and everything inside Windows  Azure, we basically have an API, both as a REST API, a PowerShell script and a command  line bash utility that you can run on Linux or Mac in order to automate everything.  And so definitely we're checking out once you actually get beyond kind of the early  basics of Azure and figure out how you kind of apply in your environment.  So pattern two I'm going to talk about is source control.  I was talking to someone about the talk and I said, you know, we're going to basically  walk through patterns you should use when you use source control.  And he said, well, what happens if you don't use source control?  And I said, well, okay, the first pattern, sub-pattern is use it.  And then here's a couple other things to talk about specifically in terms of how you use  it.  You know, definitely do recommend using source control for pretty much anything.  But especially in the cloud where you're changing things a lot and where you want to be able  to react very quickly to issues that are being reported by your customers, source control  is really essential.  And it's essential not just for your code, but the other thing you really want to make  sure you do in any type of services world is take those check-ins, you know, all those  automation scripts that I just showed you and version them as part of your actual application  solution along with your database scripts and pretty much everything necessary in order  to run or scale your environment.  So having checked in together with the code, that way when you actually iterate the code,  you're changing the automation scripts at the same time.  And if you ever need to roll back or you need to make a quick fix, you can sync the code  and know that this set of code matches these set of scripts and that everyone on my team  is using them.  And we can use them in a very agile, repeatable way.  And without having to spend lots of time trying to chase down which scripts or did Joe change  this setting?  He mentioned this, but he's not available.  He's on vacation.  You got to really make sure that you have everything in one place and it's totally repeatable.  A couple other things just to make clear.  Don't check in your secrets.  Don't check in your passwords.  Don't check in specific locations in your scripts.  It's much better to actually, not just much better, you should always parameterize your  scripts and store your secrets somewhere else.  And also as you're kind of designing your source tree, think hard about what kind of  branches you want to have and make sure that you optimize it for what I call a DevOps workflow.  So what do I mean by that?  There's lots of different ways that you can do branching on your projects or set up your  source tree.  This is kind of a pattern that we see a lot of kind of medium sized teams use where they  basically have effectively a master branch.  And this basically always maps to the code that's live in production.  And so that way if you're ever having an issue with the live app that's running in the cloud,  you can always very quickly switch to that branch, look at the code, look at the automation  scripts and know that this is always the central source of truth to whatever is deployed and  running that your customers is hitting.  What we often then see is people actually set up branches underneath that to map to  the different life cycles that they're developing.  And often what they'll do is they'll have a development branch, which is where the development  team checks into and integrates features.  If it's a big team, you might have feature branches underneath.  If it's a smaller team or you want to make sure that you're iterating and integrating  often, you might just sort of stop at the development branch and have everyone check  into that.  But it scales if you have a couple people that are working on something that's going  to take a week, you can just create a sub branch of development and then push it up through  it.  And then what we often recommend and often see people do is have a staging branch somewhere  in between master and development that you use as kind of effectively your final integration  testing or final testing before you go live in production.  And so you can use different branch strategies, but one of these, you know, the nice thing  about this type of approach, and for a small team, you could just have master and development.  You don't need to have all these different branches.  But the nice thing about this is it gives you a very agile way that you can flow your  code from your dev machine into production in a kind of, again, a repeatable way.  The other nice thing about having multiple branches is, again, it makes it much easier  and having your master or you could have a sub branch called production if you want  to snap it, always available, is that it enables you to kind of very quickly, again, react  and make changes in an agile way.  So if there's a live issue hitting production right now and you need to make a quick fix,  you can just go ahead and create a sub branch off of staging or I guess even off of master.  Make your hot fix, check it in, and then get it deployed.  And you don't have to worry about having a bunch of features that in theory are all  done but you're not a thousand percent sure that you're going to try to snap that hot fix  into.  This again allows you to kind of move off of the live production code, make a very small  surgical fix, get it live as quickly as possible, and not have to spend a lot of time integrating  and testing things that haven't hit production yet if it's an emergency.  This type of model where you have multiple branches, you're working in different branches  and you want to sometimes create new branches on the fly.  You can use it with any source environment.  Sometimes distributed based source control systems work best because you can quickly  kind of move between these and they also kind of work great in kind of a distributed team  environment.  How many people here are using some kind of DVCS solution, either get or mercurial?  Great.  You can do all the same techniques I'm showing as well with TFS.  We actually have teams within the Azure group, some that use centralized TFS, some of which  use Git.  We use both of them ourselves.  Both work perfectly well in this type of environment.  One thing that I've actually been playing with, and you'll see kind of be integrated  even more going forward inside Visual Studio and with our team foundation service and server,  is Git support.  One of the things we announced earlier this year is we're kind of adding first class Git  support in Visual Studio.  For people that haven't tried that before, we'll just go back to our Silent 2 project  here.  If you want to use Git, you can now go ahead and just say add solution to source control.  You can go ahead and say I want to check it in using either TFS source control, which is  centralized or Git.  What this will do is basically it's using the same Git command line tool in lib.lyb.git2.  Oh my God, that's wrong, that you'd use elsewhere.  What this has now done is basically added my project to source control using Git.  I can go ahead and do a commit.  I could say, if I wanted to, I could say initial check in, do a quick commit.  Basically I just went ahead and checked in code.  If I make a change, if I change this to say something else, I could do that.  I can highlight what's changed.  One of the things that's kind of nice is there's full diffing support with the VS tools.  You can forget here.  I can actually see the changes that I'm making and easily check them in.  The nice thing about this also is if I want to ever make a branch, I could basically do  that in an easy way.  Let's say I realize, oh my gosh, we've got a bad problem that we need to fix.  I could go ahead and create a new branch that I want to work with.  I could very easily make a change to it.  Create a new branch, we'll call this hotfix1.  I now have a hotfix.  I can go ahead and say this text should be different.  Quickly go ahead and check this in.  One of the things that's nice is as I switch between the branches, you'll notice here my  code and my solution explorer will automatically change as well.  It's a simple example of how quickly I can create a branch, work on something, flip back  and forth between my development and my master, make a change, go ahead, use the automation  scripts that are all checked in as part of my source control in order to push a live  update or create an environment in order to do that testing in a very kind of agile way.  This isn't the only way you can do it.  You can use material, you can use TFS, you can write your scripts in whatever approach  you want, but having these types of tools available are going to make you very repeatable,  very agile, be able to respond quickly and have a lot of flexibility.  If you ultimately want to check this in to kind of a team environment, the Git tools  that we shipped inside VS do allow you to point to a Git repo, you can go to GitHub.  One of the things that we're doing is actually now support as part of the team foundation  service that we run and will ultimately ship as part of TFS server as well is adding Git  repo support to that so that you can still use all the same TFS capabilities in terms  of project and work item and bug tracking, but integrate Git as part of that as well.  Some things to think about in terms of source control, but again the key things here are  check in your scripts as part of your solution, parameterize everything, don't check in your  secrets and then think hard about your branching strategy and really measure yourself on how  quickly can you go ahead and make a change, get it live in a very safe, predictable way.  Anytime that you think, gosh, I'm scared to make this change or we need to spend a day  or two just doing kind of manual testing on it, pause and ask yourselves what do we need  to do process wise, what do we need to do test wise in order to make it so that we could  make that change in minutes or at least within an hour and do it in a very fast way that  you feel comfortable with.  Last sort of process thing I'll talk about before we dive into more code is another pattern  here continuous integration and continuous delivery that people have probably heard the  buzzword around.  How many people are using a CI solution?  How many people know that they should be using a CI solution?  Okay.  How many people are doing continuous delivery?  That's a little bit more kind of new.  Cool.  The number of people you're doing here.  How many people have no idea what I'm talking about?  Okay.  You're being, you're not being brave enough.  I'm sure someone here is wondering what in the heck is continuous integration delivery?  Well, at a high level the nice thing about continuous integration delivery done right  is it enables a deployment pipeline so that you can integrate with your source trees,  you can integrate with your automation environment and enable it so that every time someone does  a check in, you can in a repeatable automated way go ahead and do a build, run your test  against it and with continuous delivery you can go one step further and actually take  those automation scripts and actually deploy it either by having someone push a button  or even a completely manual or completely automated way as soon as the build tests pass  into an environment that you can actually do more in depth testing with.  And hopefully what you've seen with the automation that I've shown is automating everything inside  Azure is really easy.  Because it's running in the cloud, you're not having to build servers in order to actually  or buy servers in order to actually do that.  And the beauty about integrating the cloud with a continuous integration or delivery  environment is you can now basically instead of having to wait for a server to be available  to do your testing on, you can actually on every build that you do go ahead and actually  spin up a test environment inside Azure, run acceptance tests or more in depth tests against  it, then when you're done just tear it down.  And if you only ran that server for say two hours or ten hours or a day, the amount of  money that you actually would need to spend in order to pay for that because you're only  paying for what you're using, you're only paying for the hours that that machine is  actually running.  And I can't do the conversion in my head.  But in general, like a website, the website environment that I'm running right now basically  costs one US cent per hour effectively.  Actually, the one I just deployed will be free.  But if I go to tear up, it's 1.6 cents per hour, which I don't know what it translates  into in origin currency, but it's not much.  And basically, it's less than, if you ran this for a month and you ran the environment  effectively for only an hour at a time, it would probably cost less than a latte that  you bought at Starbucks in order to actually have that environment used for your kind of  environment.  So it ends up being very cost effective, fully automated.  And again, if you haven't used continuous integration and delivery before, it's definitely  worth checking out.  And generally what I recommend going back from the branching strategies is have at least  your development and your staging environments be automated from a deployment perspective.  So every time you check in, if your build tests pass, deploy it into some environment.  Then you can run your full acceptance test, or you can have people on the team go ahead  and check.  If you want to be really bold, you could say every time we actually integrate into the  master branch, also automatically deploy the live production site.  That's kind of the nirvana that everyone knows that they should aspire towards.  I'll be candid, most teams don't do that even within Microsoft.  Just because sometimes it's nice to have some human being just sort of say, yep, we really  want to push it live in the middle of the afternoon versus, well, let's actually wait  until early morning or some point where all the dev team is available for us to go live.  So often people will have a last minute manual check or at least push the OK button before  it goes live in production.  But there's nothing that can prevent you from actually having your entire dev environment  and your entire test environment be completely automated so that all the developer needs  to do is effectively just push their source into the main tree or in one of the branches  in the main tree.  And you can basically build it, run your unit tests, deploy it, run your acceptance tests,  completely automated, and have as many developers on the team going ahead and doing that 24.7,  very, very cost effectively.  There's lots of solutions you can do to enable this.  There's a bunch of great talks throughout the conference about integration and delivery.  I can't do justice here, but hopefully I just wet your appetite.  One thing that we're also working on ourselves, so there's things like TeamCity and other,  Hudson and other environments that you can use in order to do CI and CD.  One of the things though that we're also working on is part of our team foundation service,  which is free up to five people, and you can sign up and actually play with it today,  is actually trying to make it really great to do this type of continuous integration  and continuous delivery without you having to set up anything.  So it runs as a service, it actually runs on Azure, it supports both Git and TFS, and  it now has an elastic build service so that you don't actually have to have build servers  lying around.  Instead, every time you push your code in, it can automatically kick off a build using  servers that we maintain, and we don't charge you as long as you do a certain number of  builds, then you can have reserved build servers if you want to pay a little extra.  And we basically do continuous integration, we can deploy to Azure.  They also just recently added load testing support, so once it's actually in an environment,  you could start throwing load at it in order to measure performance and stability, and  they just recently added some team room collaboration and some more agile project management capability.  So if you're looking for kind of a turnkey solution, that's one you can also go ahead  and look at.  So now we talked a little bit of process, let's now drill in more into code, and I'm  going to walk through a couple of best practices here, both on the website as well as with  enterprise integration and then data throughout the rest of this talk.  So let's start with web.  How many of you here are doing web development or building apps?  Great.  A lot of these best practices apply both for web as well as for custom mobile back ends  if you're using, say, ASP.NET web API, you can apply these as well.  And at a high level, some of these ones that I kind of listed here from a best practice  perspective that I kind of recommend, the first two kind of just are pretty obvious  and then we'll drill into some of the more detailed ones a little bit later.  But one is, you know, wherever possible, be stateless on your web tier.  In other words, try not to use session state, try not to have anything that needs to be  stored in the web server in a stateful way.  Try to have it be as stateless as possible.  There's a couple of reasons for that.  One is if it's stateless and you put those machines behind a load balancer, it makes  it really easy for you to go ahead and just keep adding machines as you need capacity.  And it also makes it really easy for you to shrink machines or turn off machines as you  don't need capacity.  In an environment where you're only paying for what you use, that ability not only to  expand but also to shrink your capacity based on load translates into huge savings.  It also makes it architecturally much simpler to scale out your solution.  So if possible, avoid session state since that does add some state.  If you do need to use session state, don't store it in a database.  We have a nice cache provider that you can use on Azure that we recommend instead.  And that actually scales out and is much more cost effective and much better.  Recommend using a CDN.  For people who don't know what a CDN is, it's a content delivery network.  This basically allows you to edge cache your JavaScript as well as your images so that  if your customers are accessing your website, they don't always have to hit your web server.  Instead, they can hit a cache location somewhere closer to them.  In particular, if you are reaching a broad audience, that can help and just speeds up  the overall load time of the site.  And then this last one is something that, I'm curious to see how many people here are  using the.NET 4.5 async support.  People know that there's async support.  Cool.  It's really cool.  Definitely recommend using it, both for your on-premise, this is based applications.  So if you're running existing Windows servers inside your organization, but especially also  in the cloud.  And it allows you to kind of avoid making any blocking calls within your solution and really  enables you to scale out in a much richer way.  So for people that haven't seen it or they've heard about it, this is sort of a simple example  and we'll walk through this fix it code in just a second of where I'm using async and  some of the benefits that it provides.  So basically you can see now with the latest version of ASP.NBC, web API and web forms,  we have full async support.  You can effectively just go ahead and mark a method as async.  Then you typically return a task of T. And then I can go ahead and every time I make a  call to an async API, I can effectively say await on it.  And what this does under the covers is the compiler will then automatically generate the  appropriate async code so that as I'm waiting for this fix it repository fine task by ID  async method to go hit the database, ASP.net can unwind the worker thread and use that  thread to process another request.  And the benefit there is instead of, you know, let's say the server has 10 worker threads,  instead of having a lot of them blocked waiting on database calls or remote network calls,  it can process a lot more requests much more efficiently.  And you could do this in the past even with ASP.net one because it did have async APIs,  but it was frankly kind of a nightmare to write that code and very error prone because  you had to write a lot of async code in order to handle all the error conditions.  What we've done in.net four or five has made it really easy.  So just directly within C sharp or VB, you can use these keywords in order to express  the same intent and really scale out your app in a great way.  A lot of people, you know, often talk about Node.js as an async based way in order to  build server apps.  We support Node.js also in Azure.  The nice thing about the async support that we now have inside.net is we do all the same  things.  We provide all that same capability.  But I think from an API perspective, especially if you're coming from more of a procedural  background, it's a little bit cleaner.  You get full intelligence and full debugging.  And then the benefit is the actual code that's running is also running through the standard  CLR Just-in-Time Compiler.  So you're running very, very optimized code on the server so that when your code is running,  it's actually going to be much faster than, say, an interpretive environment.  One thing that's cool that I'm taking advantage of in this app is we shipped as part of web  forms, MBC and Web API async support for the web server, but our data libraries didn't  support it yet.  You could call web services, you could call sockets or do file system IO async.  But the most common pattern for most people building web apps is to hit a database of  some shape or form.  We're adding into entity framework six async support.  And this is now available in preview.  And the final release will be out in a few months.  And what this means now is in my fixit repository class that I've defined here, you'll notice  that I'm able to access an entity framework context.  This is just a standard code first database context.  I can then have my repository classes also be async.  And then I can go ahead and call now my database and insert and retrieve things in a completely  async way.  And this now means both my data access library and my web tier can unwind the worker threads  and run code in a super efficient way.  But anytime I hit my database, I'm not blocking and I can actually return things again in  scale much better.  And what's cool is this works not just for simple finders or inserts and deletes.  It actually composes with link queries as well.  And so this is an example inside the code we'll walk through in just a second where I'm actually  writing a complex link query and using where clause is in order buys.  And what you'll notice here is this whole method is async so that this whole complex  query is going to be passed to the SQL database.  The thread gets reused for another request.  When the SQL database returns it, we can re-queue the thread, continue execution from the exact  same place logically in the code that it left off and continue running.  And now you can basically not block ever on the server and have an app that will scale  better than pretty much any framework out there on the server in a really clean way using  the C-sharp or VB or other.NET language that you already know.  So I'm using this heavily within the application and we'll walk that code in just a second.  Other things here in terms of what I'm using inside this web app just to kind of explain  some basics.  I'm taking advantage of a feature here of Azure we call websites.  This is basically a way that you can go ahead and host a web app inside Azure without having  to host and run your own virtual machine in order to do it.  And so we actually provide all of the mechanisms necessary to basically run that website inside  Azure and we'll do the hosting and the scale out and the recovery for you automatically.  It works with ASP.NET, it works with Node.js, PHP and Python and it enables you to kind  of very quickly deploy in seconds.  And so you can make changes and quickly refresh them usually in a matter of less than 10 seconds  from the point you hit deploy to the point that it's live in production.  Now what's great is you can deploy on a free environment and then scale up as you need to.  And basically the way this works, it's simple.  You saw me earlier create the website and then just deploy to it.  Under the covers behind the scenes, it's kind of a complex environment.  It's really kind of building and providing for you a lot of features that if you're using  purely a virtual machine in order to set up and manage IAS, you'd actually have to build  yourself.  And this diagram here on the right is sort of an example of what this environment looks  like.  Basically when you show up and you say I want to run this website, you can choose how many  machines you want to run it on.  So I can say I want to run on one virtual machine or I want to run on two virtual machines.  And it'll basically stand it up and create it for you.  And then what the service, the website Azure services also doing is provides a deployment  endpoint so that when you say I want to deploy my app, whether it's through VS or whether  it's through an automation script, it'll automatically deploy onto those machines the bits that you  actually go ahead and produce.  And so it does all of the laying down the bits, setting them up, making sure IAS is  ready in order to use them.  And then when a customer shows up and types in the URL, they hit those machines.  Now the cool thing also about the website services, they don't hit the virtual machine  directly.  The Windows Azure website runs a pool of what we call load balancers that are using a level  layer seven application request router load balancer, which again you can run yourself.  But the beauty is it's set up for you automatically and they'll route that request to the appropriate  machine.  If a lot of requests come in at the same time, they'll automatically route them to all the  different virtual machines and it uses a fairly smart heuristic so that it sends requests  both based on affinity as well as based on actual the queue depth inside IAS as well  as the CPU on the virtual machine.  And so basically we can be very smart in terms of the load traffic that's actually distributed  and all that's built in.  And then the other thing that's nice about it is if a virtual machine goes down, it'll  automatically pull it from the rotation so no more traffic goes to it, spin up a new  instance and then automatically start directing traffic to it.  And so all this kind of mechanics happen behind the scenes, all you need to do is basically  just say create me a website in one line of PowerShell or just go in the portal and create  site and you get to take advantage of all this.  And that's what we're doing within the app.  So let's walk through the code and look at this real quick.  So basically this is my fix it app here and you can see it's just a standard web project.  I can run it.  I've got a logging library and a data access library that we'll look at.  And so when I hit control at five here you can see this is running in my local dev environment  so I can do everything offline if I want to.  In terms of kind of how it's implemented it's using ASP.NET NBC.  So let's just go back here and we'll look at logging and other things in part two.  But you can see basically I've got controllers.  I got a home controller, a task controller and a dashboard.  The dashboard is gives me kind of crud support.  And again you can see pretty standard action methods that are exposed here.  They're all doing async.  And so you can kind of see a simple example here where I have details get passed in.  It calls a repository, returns hp.found.  If it didn't find it or basically just renders the content there.  One thing you'll notice is I'm passing in as a constructor argument to all of my repositories  and all of my controllers a few parameters.  So my controllers all get an itask repository.  And if you go and look at the repository you'll see it gets passed in a logger interface that  it uses as it's doing its data access.  And basically what I'm taking advantage of is dependency injection.  And specifically the auto fact dependency library.  And so there's a couple different ways you could do dependency injection.  This is a nice framework so instead of me manually passing in these things what I did  inside this code is take advantage of auto fact.  And all I need to do is say every time you see an I fix it task repository in a controller  or an I logger or an I photo service just pass in this specific instance into it.  And so basically in just sort of these six lines of code I can now very cleanly inside  any of my classes that I use inside my framework just go ahead and get my dependencies passed  in.  Makes it a lot easier for me to go ahead and test.  And that basically ends up being kind of my data library kind of a nutshell.  And again it's running inside Azure.  So if I go ahead and click on this.  This is a Europe instance here.  I can drill into this particular app inside Azure.  And you'll notice built into Azure is a dashboard so I can see how many requests that was probably  from last night and that was when I was running it just a few minutes ago that I actually  hit on it.  If I want to scale it I can click the scale tab or again I can set a power shell command  so everything I'm doing here I can also go ahead and run.  And if I wanted to say hey let's deploy this on six medium sized virtual machines all you  need to do is hit save and it will auto scale now this app in a matter of about 10 seconds  to five more virtual machines that are each about three and a half gigs of RAM and my  app is now running on it.  So basically it was just a few commands or through the portal I can very easily deploy  this app and then scale it up or scale it down.  And that whole environment that I walk through where I have load balancers automatically  in front of it I'm doing automatic protection in case that app ever goes down and I'm running  it in a completely async way all just works.  So you can do this pretty much with any ASP.NET app and take advantage of it really easily.  One last thing I'll just mention real quick is if you click the configure tab you'll notice  here a bunch of app settings and connection strings that are available and this is basically  a way when I ran that script up front one of the things I briefly touched on is how  you can go ahead and script these as part of the environment.  So when I created this environment as an example here I basically specified that I want to  use these settings.  Some of them are never changing a few of them like my storage account name are dynamically  created elsewhere in the script and passed in as arguments.  One nice thing about this model here is it allows me as a developer I can basically have  dev settings inside my web.config file that I use.  So I just do app settings or get connection string from my config file and then at runtime  this allows me to override the settings that are in the web.config file with production  based environment.  So you'll notice here from my dev environment here I have a local DB data source checked  into my web.config and so all the developers will just use a local database on the machine  as they're doing development.  And then at runtime when I create my environment in an automated way that script created a  database for me and it automatically set a production connection string on that web server  and now when my app runs in this environment it will automatically connect to the production  database instead of my local DB.  And so this provides a really nice way that you can override in an automated way and it  makes it really easy so you're not checking in secrets into your source code so you don't  actually have to modify the web.config as part of your build process.  Instead you can use this app settings and connection strings model to basically override  these values at runtime and have only a set of approved folks know what the production  settings actually are.  So again the scripts will show you how to do that.  So we talked about some web things, let's now talk about security and then we'll talk  about data.  And so what I want to talk a little bit about is this pattern here which is single sign on.  And one question people often ask me is okay I'm building primarily apps for the employees  within my company, how do I host it in the cloud and still allow them to use the same  security model that they already know and use in their on-premises environment when they  hit my app that's running inside the firewall.  And one of the ways that we're kind of doing to enable this and you'll see some announcements  come out in the next couple weeks is through something we call Windows Azure Active Directory.  And this is basically providing Active Directory in the cloud.  It integrates with an on-premises environment, enables single sign on within all your apps  and it does it in a way that's open standard.  So I can use SAML, I can use OAuth and I can use OAuth 2 in order to connect to it and  integrate within my applications.  And the beauty is we're making it really easy in order to actually set up.  And so you can kind of just build a diagram here.  Imagine you have an on-premises Windows server environment where you're using Active Directory  to have your employees sign on.  And so you kind of make this work just like today.  What we're allowing you to do with Azure is create a directory in the cloud and it's a  free feature so you can do it without having to pay anything.  And that directory can be used also to sign on.  And you can have that directory only have basically be disconnected so you can put anyone  you want into it.  Or the cool thing is you can connect it to your on-premises Active Directory at which  point all of the users that could log on on-premise can now also authenticate using Azure without  you having to open up a firewall, without you having to actually deploy any custom new  servers.  You can leverage all the existing Active Directory environment that you know and use today.  And at that point then your mobile devices and your web apps can authenticate in the  cloud and you could basically have your app that you hosted in the cloud, including your  enterprise internal-facing apps, now have enterprise single sign on.  You can also use this for third-party apps.  So for example, if you're using Salesforce.com or Google Apps or Office 365, you can use this  directory in the cloud in order to enable single sign on with them as well, all in a  secure way.  And the beauty is anytime a new user gets created into your organization or anytime a password  changes, they just use the same mechanism they use today on-premise and it will automatically  flow and apply immediately in the cloud as well.  So it makes it very secure.  Doing this is pretty easy.  Again, you can do it through PowerShell.  I'm going to do it through the portal just to kind of illustrate the concepts.  Basically you just go inside Azure, you click on Active Directory.  If you don't already have a directory, there's a little button here called Create One.  Right now you can only create one directory and you can't delete it.  So think carefully about what you name it.  I named it Scott Guthrie, which is actually very confusing because Scott Guthrie is now  both a directory as well as a user.  The ability to create multiple directories is coming, but right now it's only one per  account.  And basically, within this directory, I can add users.  So we basically have full support for creating and managing users within this environment.  So if I wanted to, I could go ahead and create Tom and add this and I can give username last  names, pick the roles, and it will go ahead and create a new account for them in the system.  And once I do that, then they can go ahead and log in using this cloud directory.  What's cool of those, I can also click this directory integration tab.  And if I enable this and then download a tool that there's a link for, I can also then sync  my existing on-premises active directory that I'm already using inside my organization  with this cloud, at which point all the users in my organization will show up in this directory  as well.  And at that point, then, I now have a lot more users and I can do single sign-on within  all my apps in order to integrate them.  And doing this is really easy.  We just shipped a tool actually last week that you can download.  Again, it's a free tool and the Windows Azure Active Directory itself is free to anyone.  You download the tool, you click Next, you enter in your Azure account details, you click  Next, you enter in a domain user account that's on your corporate network.  So this is your existing on-premise network.  You click Next, you click this enable password sync if you want to go ahead and hash your  passwords and store a hash version in the clouds.  We never know what your passwords are.  It's a one-way hash.  Alternatively, if you never want to send any passwords, including hashes, you can also  use ADFS and set it up.  So a few extra steps there, but that also allows you to use the cloud directory as well.  But for this simple model, just go ahead and click the hash.  Click Wait a few minutes and you're done.  And at that point, then, if you run this on a domain controller, just one domain controller  inside your organization, it can be Windows Server 2003 or higher.  All your users are basically in the cloud and you can now do single sign-on from within  any web or mobile application.  Again, using SAML, OAuth, or WSFed as an API head.  This makes it really easy in order to actually integrate enterprise security in this model.  So let's go ahead and walk through how you do that.  It's really simple.  Basically, you can go now into the portal and you can create an application.  Again, you can also do this through the command line.  And all you need to do is just say, what's the app I want to run?  So I can call it fixit web 2.  I can enable single sign-on.  I can also give directory access so you could read or write properties in the directory  on users so you could see what their phone number is, whether they're in the office when  they last logged on, in a kind of graph REST API way.  So if you're ever familiar with Facebook, think of this as like an enterprise Facebook  graph where I can just say, just do sign-on.  And all I need to do then is basically paste in the URL of where my app is deployed and  I give it effectively a URI secret that embeds as part of it.  And then you hit OK.  And at that point, I can have any number of apps deployed.  This is the one that I have inside North Europe.  And basically, I just paste in this key into my web.config file.  And this works for any app in the tenant so you don't have to configure it.  And at that point, what I can do inside the new version of ASP.net that's coming out in  about a week and a half.  So now, let's go ahead and do that in room numberconf
Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_0_107.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_108_155.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_156_7751.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_7752_8459.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_8460_9035.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_9036_9539.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_9540_9971.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_9972_10307.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_10308_10379.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_10380_10811.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_10812_10883.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_10884_11411.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_11412_11459.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_11460_15803.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_15804_15887.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_15888_16835.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_16836_17699.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_17700_17747.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_17748_17807.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_17808_17891.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_17892_17951.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_17952_18143.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_18144_18251.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_18252_19379.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_19380_19451.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_19452_19691.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_19692_19811.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_19812_19883.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_19884_20207.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_20208_20291.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_20292_20351.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_20352_20771.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_20772_23483.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_23484_24179.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_24180_25451.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_25452_26303.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_26304_27275.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_27276_27479.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_27480_29327.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_29328_29771.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_29772_30395.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_30396_31367.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_31368_32867.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_32868_32915.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_32916_42035.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_42036_47771.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_47772_65123.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_65124_66275.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_66276_76259.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_76260_79283.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_79284_79355.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_79356_80087.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_80088_81035.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_81036_81167.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_81168_81215.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_81216_82571.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_82572_84923.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_84924_84983.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_84984_85883.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_85884_86231.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_86232_87143.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_87144_87311.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_87312_89147.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_89148_89231.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_89232_89399.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_89400_90239.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_90240_90611.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_90612_90731.png Scott_Guthrie_-_Building_Real_World_Cloud_Apps_with_Windows_Azure_-_Part_1-68215538_90732_90832.png