Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

Build Your First Cloud App: An Introduction to Windows Azure Cloud Services

0 (0 Likes / 0 Dislikes)
  • Embed Video

  • Embed normal player Copy to Clipboard
  • Embed a smaller player Copy to Clipboard
  • Advanced Embedding Options
  • Embed Video With Transcription

  • Embed with transcription beside video Copy to Clipboard
  • Embed with transcription below video Copy to Clipboard
  • Embed transcript

  • Embed transcript in:
    Copy to Clipboard
  • Invite a user to Dotsub
[Craig Kitterman] All right, good afternoon! Thank you guys all for coming out this afternoon. I actually thought everyone was going to be moving on to dinner and drinks and things like that. Always the last session of the day is hit or miss, so I really appreciate everybody taking the time to come here. My name is Craig Kitterman. I'm a Product Manager on the Windows Azure Product Marketing Team. Today I'm going to talk to you a little bit about the cloud services of Windows Azure and really how to get started with cloud services. This is an introductory session, so if you're expecting super deep dive, this isn't the right session for you. This is very much an introductory session. So we're going to talk about how to develop apps using the cloud services model, some of the cool things you can do with it, and then we're going to talk about some of the general sort of architectural principles that you need to keep in mind when building and designing applications for the cloud. I imagine many of you today are building on-premises applications, some WinForm stuff, some web stuff, and there's a few different things you need to keep in mind to really take advantage and get the full capability of what the public cloud has to offer. So with that, let's dive in. So what is the cloud? I always start with this question, because you probably heard 100 different people answer this question 100 different ways, and if you believe some of the hype, it's probably something like this, right? Of course that's not the case. As much as I wish it were, it's not the case. So let's take a practical look at—when we're talking about cloud, what are the types of things we're actually talking about? What are the services we're talking about delivering? So here are some more buzz words for you: IaaS, PaaS, and SaaS. IaaS is Infrastructure as a Service. This is the very simple notion of being able to get virtual machines on demand from somebody else in the cloud. Instead of provisioning those things on your own infrastructure and your own data center, you spin those up on a third party's infrastructure. In the case of Windows Azure, you go through the Windows Azure portal and you request a new virtual machine from Microsoft. That virtual machine gets provisioned in our data center, and you're handed an IP address as an end point. You can connect to that machine, install what you want, do what you want with it. It's yours; it's just running in our data center. That's infrastructure as a service. Platform as a Service, which is what we're going to talk about primarily today, is the notion of going a little bit further up the stack. You're not thinking about things like operating system and configuring the runtime for that thing, patching and managing all the security updates and so on. That's what you have to deal with when you're dealing with a normal physical machine, and that's what you also have to deal with when you're dealing with infrastructure as a service, and platform as a service— the fender that's providing you that platform service capability actually does all that stuff for you, so you don't have to think about security updates or updating your runtime or any of that stuff. It's all done for you, and what you get instead as a developer is a container, a set of API's that you can hook your app into and that you know are going to be there, and they're going to run. So you write your code and you deploy your code as a unit. You don't have to worry about any of the other stuff, okay? That's the Platform as a Service model. Then of course SaaS—applications delivered to you as finished service. It's typically through a browser or some kind of device. We're all familiar with those. So today we're going to talk primarily about Information as a Service and Platform as a Service. We're going to focus on Platform as a Service, because that's the focus of the talk, but we will touch on Infrastructure as a Service, as well. What what can it do for you? You're all here probably because you haven't yet played with the cloud much, and you're wondering, "Okay, what can it actually do for me? Why am I here?" Well the first thing is agility. Early on when we were talking about cloud, the notion of cost came up a lot—what does it mean in terms of cost? There are a lot of cost advantages to doing certain things in the cloud, but primary benefit particularly for developers is agility. Imagine not having to wait around for infrastructure to be provisioned, for you to be able to go spin up your own development and test environment on demand, when you need you need it, get the resources you want, run your tests, run your code, test your code, spin those things back down without having to talk to anyone. I heard a horror story from a developer a few weeks ago. He has to send a fax to somebody to get a server provision so he can run his tests. I didn't even know fax machines still existed! But that's the reality for some people, particularly in larger legacy-type enterprise companies. So having that agility, be able to do what you want to do and be empowered as a developer to get your work done quicker and easier. The other great thing is you don't have to reinvent the wheel! How many times have you written identity authorization code or certain bits of your storage code writing data to and from a database? There's a lot of types of code that we as developers have to write over and over and over. It seems like we have to write over and over and over again. As tools have matured, as frameworks have matured, that's gotten better, I think, but there's still a lot of things— like identity provider is actually a good example. How many of you in the room have implemented the Facebook or Twitter API's? A few. I did it about 5 years ago when it was pretty early on, and it was really painful. I had to go learn OAuth and all this other stuff. Well guess what? Lots of other people have already written that code. Why can't I just use that? So great thing about cloud providers who provide platform as a service and other types of services is if that code's been written, there's an API that you can just call in order to add that capability to your app, and we'll talk a little bit more about that. This particular caveman loves API. So these application building blocks are a core part of building cloud service applications. It's not just your web code or your service code. It's all the other stuff that you can hook into very easily with standard API's. Things like big data, database on demand, rather than going and having the provision servers and configure SQL server— I, as a developer, never used to like to do— is go set up the database server. Instead I can now, with a few clicks, get a database and a connection string, and I'm off and running. I want to spend my time on the app, not on the provisioning stuff. Storage systems that are non-relational, key value storage, no SQL, if you will. Being able to configure caching, identity, implementing identity providers in my app. If I want to accept Twitter identities, I want to accept Facebook, Google identities, Yahoo identities. All of that stuff is available to me by just writing a few lines of code, dropping that in my app, and now I can accept those providers as identity providers for my application without having to go understand OAuth open exchange protocol. So that's the power of these building block services. The other core tenant of cloud— you heard a lot of this this morning with the announcement of the permanent billing now in Windows Azure. It's paying only for what you use. Again this is a powerful construct particularly as developers who are going to be using the infrastructure potentially for short bursts of time. There's no need for your dev environment, for example, to be running all night while you're asleep, so you can shut that thing down before you leave, either through a browser experience or with a script, and you're only paying for what you use, and in fact, if you're an MSDM subscriber, you're probably not paying anything extra for that. So that's really a core tenant of cloud: Self-service, agility, and paying only for what you use. In the traditional model, when you were going to buy infrastructure for an application, somebody had to make a somewhat educated decision about how many servers do we actually need to service our customers or our expected load for this app? And one thing's for certain: They guessed wrong. It's always wrong. They either wasted capital expense by buying too much hardware for fear of not being able to serve their customers or they bought not enough hardware and they were under serving their customers. It's always wrong. So being able to match that demand curve in the cloud by spinning things up and spinning things down as that demand curve fluctuates, which it does, really gives you a lot of agility and cost benefit and paying for only what you use. So let's look into Windows Azure and talk a little bit about Windows Azure's implementation of platform as a service in what we call cloud services. First I forgot, let's talk first about the global infrastructure. Under all these great cloud services, the computer models, these application building blocks, we have a bunch of physical hardware. Windows Azure has 10 data centers today, and we're growing, distributed around the world, and everybody always asks me, "What's it look like in one of these data centers?" So I actually wanted to show you a little picture about what it actually looks like in there. These are container based systems—very modular. There's hundreds of servers in each one of these things and switches and networking gear. Their wheeled into place by tiny, strong men and hooked up to all their respective utilities. They get plugged into power water for cooling and a network— you can see the pipes there, and that's about it. These are complete lights-out operations. Nobody ever goes inside those sealed containers. Basically we wait until the stuff inside has sort of decayed or failed to a certain unacceptable level, and then we take those things out and put in a new one, and the old one gets refurbished. So that's how we operate these data centers. They are operated by the same folks that run all of the Microsoft finished services, MSN, Hotmail, Office 365, and the like, so they really know how to do this. This modular operation gives us a lot of benefits in terms of scalability but also economic benefit that makes things better for you as the user of Windows Azure. So now let's talk about platform as a service. Windows Azure's implementation of that, which is called cloud services. It allows you to build infinitely scalable apps and systems. That means you can compose apps of multiple different tiers using what we call roles, and we'll get into that in a minute, and automated application management. This is an important concept, particularly in platform as a service. What happens automatically— the Windows Azure fabric is always looking at and monitoring your application as it runs and making sure that it's in a healthy state. If it's not in a healthy state, it actually handles fixing that for you in many cases, so let's take a look at how this actually works. So we start by building an application. Let's just say we have a simple web application, web application. We built that in Visual Studio just like we always have, but the difference is now we upload with what's called a service package into Windows Azure, and this can be done through a browser. It can also be done directly from Visual Studio, and I'll show you the Visual Studio method. That service package is nothing more than a glorified ZIP file. It contains the code for your app, so if it's a web app, it's your ASPX files and all of your images and whatnot, and it contains some configuration metadata, and that configuration metadata simply tells Windows Azure how to run your application. Now if you just want to run a .net app, like a application, you don't have to set up really any special configuration information. Windows Azure already has .net configured in that container by default, and your app gets uploaded, it gets deployed, and everything is done. You can put special configuration data in there to install special software. You can have a startup script that does anything. It configures the runtime any way you like it. There's a lot of flexibility here in terms of what you can deploy. So once Windows Azure takes that service package, it first looks at the configuration data and says, "How many instances of your app do you want?" And in an instance, at the end of the day represents 1 virtual machine, so it's simply a number in a configuration file. I can say 1. I can say 4. In this case I said I wanted 4 instances of my app. Windows Azure reads that data and says, "Okay, I'm going to go provision you 4 virtual machines "somewhere in this massive data center that you've chosen, "get them all ready with the latest guest operating system, "make sure it's all patched and up to date "with all the latest goodies, and then we're going to—" And then the next phase is—we're actually going to put your code on those 4 VM's in a very, very consistent way. I'm getting too far from the receiver. So now we have 4 virtual machines that have exactly the same bits on them that are running our app, okay? But that's not enough, because now nobody can access our app. It's running on VM's on a data center somewhere. The last thing that happens is Windows Azure automatically sets up network load balancing across those 4 instances that I requested, so all the requests to my web site, in this case, get equally distributed across those 4 instances. Okay? Now when something bad happens, one of these VM's goes down because some underlying infrastructure fails, which it does—it wil. Windows Azure automatically detects that that instance is down, goes and reimages a brand new VM, and then adds that one to the load balancer. So this can happen in the middle of the night If anybody here has ever received a page late at night or in the middle of the night because the hard drive failed on a production machine or something like that, you'll understand how important this is. You may not ever even know that happened. You probably won't unless you set up alerts to get told when this happens, but it happens automatically. That's the beauty of this model—you don't have to think about those kinds of things. Okay? Now our web site just got really popular. It's on Oprah's favorite things or something like that. We need to scale, and we need to scale fast! So I can go into Windows Azure— and that should be 4, not 2— but I can go into Windows Azure now, and all I need to do is literally drag a slider bar from 4—or in this case 2 up to how ever many instances I think I need to handle this spike in traffic. So all I do is drag that slider bar. In this case 6. We click Save. Windows Azure starts provisioning more VM's, imaging them with our code, and getting them on the load balancer. Now this thing explodes and it becomes viral on the Internet, and I need way more than that. I simply drag that slider bar up to 92 or what have you, and Windows Azure does the same thing. There's no difference—it goes out, provisions 92 more VM's, and in just a few minutes, I've got low balance traffic across 92 VM's with a slider bar. That's the power of scalability of this model. And when the buzz dies down, which it will. Oprah's buzz died off, and I don't need all of those 92 VM's anymore. Drag the slider bar back down. I have some new customers that I didn't have before, so now I need 10 instead of 4 or 6, but I don't need 92, okay? So the other cool thing that we added to Windows Azure cloud services recently is the ability to add a cache to your roles—your instances. So you can have a distributed cache that is shared across multiple instances. So in the case of where I have 4 instances of my app, I can say, "I want 300 MB of each of those instances to be in a shared cache." So effectively I have a 1.2 GB cache that's shared by all my instances, but in terms of the underlying use of resources on each VM, I'm only using 300 MB. You can also set it up such that you have dedicated cache roles where you basically—at the end of my infrastructure provisions just dedicated VM's for your cache, and then all of your instances of your app just talk to that cache, and this is a really simple thing to set up, and I'll show you really quick how to configure that, as well. Then you can scale that out, as well. If you want more cache, you just simply scale it out, and then everything still works the way it worked before. Again it's about focusing on the apps. You're developers. You don't want to focus on infrastructure. Let's focus on apps, and what does that really mean? It means focusing on business, delivering business value, because you—the developer, the expert who knows how to write the business logic for the app is not spending time doing things that you ought not be doing, and at the end of the day, that's what's important, right? That the business is successful. You're successful. Everybody's happy. I'm not going to go too much into this. This is something for probably another talk. If you want to go off and do some deeper talks, there's a lot of different services that are available on Windows Azure here, including the building block services that I talked about, which are sort of the green boxes on top. Those are the things you can hook in with simple API's to your app. We also have a bunch of other infrastructure or core services, let's call them for hosting and running apps. Storage systems, relational database, SQL database, non-relational store, as I mentioned. We have virtual machines. We have cloud services, which we're going to talk about today. We also have something about web sites, and I do want to hit on web sites for just a second. So if you've look at all at the Windows Azure offering, we have something called Web Role, which is what we're going to look at today, and we have something called Web Sites, and it can be confusing in terms of which does which. Web Role was introduced first, and it's designed for enterprise cloud scale types of applications that are multi-tier and complicated deployments and whatnot. Web Sites was initially designed to really get up and running quickly. It allows you to deploy even faster than with cloud services, run some different types of languages and run times out of the gate like PHP and nodeJS and some other things. It gives you some of the scalability benefits, but not all of the same benefits. If you hear people talking about Web Wole versus Web Sites, they're 2 different offerings, they can both run a web site, but they have different benefits and capabilities. So just real quick— when we're talking about Web Role here, which is what we're going to cover, we have a lot of capabilities that Web Sites doesn't have. We have environments for staging and production, so when you deploy that service package into the cloud, you can say, "I want that to go into a staging bucket" or "I want that to go into the production bucket." With cloud services, you get this, and what's really cool about it is you can deploy up in the cloud up into a staging bucket. It will give you back a URL that has some funny GUI on the front, so it's effectively—nobody can find it. You click on that. You can run all your smoke tests and all your final testing before you roll that into production, and when you roll that into production, you click a button, and it literally does a virtual IP swap between staging and production. What was in production goes to staging, and what was in staging goes to production. It's a very easy way to test it out before you go into production. Web Sites doesn't really give you that. Once you deploy, it's just like a more traditional hosting model, and once you deploy—write your files out there, that's what's in production, so there's no sort of final backup button. The great thing about this sort of switchover thing is when you roll something into production, and then you realize there's an issue, you can click the button again and it goes back, so the old build goes into production, and then you can go figure out what's going on. It's happened to me several times, so it's a really nice feature. One of the other things you can do with the Web Role that you can't do with Web Sites is actually remote desktop into the underlying VM. Now in a perfect peer platform as a service world, you would never want to do that, because you shouldn't be bothered with such things as operating systems and whatnot. But if you're trying to configure your startup script, because you have some complicated software or something that needs to get installed on your underlying instance VM's, you may want to RDP in there just to take a peak and make sure everything got configured properly so you know your startup script works. This just gives you a little bit of control to peak under the covers when you need to, but you would never actually RDP, remote desktop in, and then install a bunch of stuff, because then it would immediately be blow away, because a Web Role is stateless. It doesn't persist everything to disk, so everything needs to be configured within your startup script. There's a few other things. The virtual networking support is the next most important, and then we'll move on. This is the ability to create virtual networks in the cloud. You may have already heard we have this capability in Azure, and you can even connect those virtual networks that you've created in the cloud back with your existing on-premises infrastructure— your existing datacenter. So you can provision new services in the cloud that can talk over LAN IP's to your existing stuff. You can do that now with cloud services; with web sites, you can't. Web Site is basically—if you have a web site with a database, it's great, but if you need some of these more complicated services, Web Role is for you. So now that we got that out of the way, let's take a look at how to build one of these things. All right, we're in Visual Studio 2012. I've got the Windows Azure SDK installed. It's a very easy thing to install at Windows Azure Dev Center— just go there, click the thing, it'll run the web platform installer, and get you all set up and configured. Once you have that, it's very easy to create a new cloud service project, so let's do that. File > New Project. Under whatever language you prefer—I prefer C#, I'm going to select Cloud, and you'll see here Windows Azure Cloud Service. Let's just call this one breakout sample. I have the normal ability to add source control or do anything else you can do with a normal VS project. So now what this is going to do is actually create sort of a shell for my Cloud Service Project, which is really the bit that holds that configuration data. What separates a regular web application from a cloud application is that—remember that extra configuration data that's in the service package. But what it's asking me for now is— okay, we're going to go create that configuration shell for you, but what type of code do you actually want us to run? There's 2 types of code you can run in Windows Azure Cloud Service. You can run Web Role, which is effectively an IaaS-based workload and web site, or you can run what's called the Worker Role, which is basically more like a Windows service. It's basically a loop— a wow loop that loops forever that allows you to do things in the background asynchronously, and I'll show you an example of an app that does that in a few minutes. For this sample, we're just going to say, "I want an MVC 4 Web Role." And that's all I'm going to do for right now. So I'm just going to go through the prompts and create my cloud service. So you'll see here— this is just a normal MVC 4 project, and then I have this additional project within my solution that has the little cloud here, and that's where all this configuration data is held. So if I click on one of these configuration files, you can see I can set things like global connection strings for my cloud storage account, database connection strings, all that kind of stuff—particular app settings. I can actually abstract those back out of web.config and put them in the cloud service config, and what that allows me to do is actually while my service is running in the cloud, I can go up into the Windows Azure portal and tweak those configuration values, and the next time the code comes through, it'll pick up the latest one from the service config, and I don't need to redeploy, so it's just a nice place to store configuration data. You'll see here— this is the important one—sorry, let me zoom this in. You'll see here this instances count = 1. That just tells them how many underlying VM's do you want this thing to run on? So I'm going to go ahead and just make this 4 for the purposes of this exercise, and then we're just going to go ahead and do F5 here. And what you're going to see is not particularly exciting, but I'll explain to you why it's not exciting. So this is your standard MVC 4. There's no difference here, except there is. This thing's actually running inside the Windows Azure emulator, so let's take a look at what that looks like. So what we have here is a tiny piece of software that runs on your local machine that emulates what's going to happen when that thing gets deployed to the real cloud, and that includes both the runtime container for your application, as well as storage, so if you're using table storage or you're using queues, basically we have simulated the storage API's from the cloud as well, so you can test how your app's going to behave when it goes into production right on your local machine using local storage. It actually backs the storage API's with SQL, but you don't need to know that. It just works. The interesting bit here is when I expand this—it should have gone to 4. Maybe I didn't change something right. Normally this would have 0, 1, 2, 3, and deploy all 4 of the VM's, so let me try that again. Maybe I didn't save something. Oh, I know. I need to change it in this file. So let's try that again. I have 2 configuration files here. One is my local version, and one is my cloud version, and I said in my cloud version, which is what gets read when you actually deploy it to the cloud, I want 4 instances, but I failed to change the 4 on my local version, so when I run it locally, I also want 4 versions. So now if we got back into the Windows Azure Emulator, I should see 4 instances there. So I actually have 4 tiny runtime containers, if you will, running in parallel, and inbound request that I make to this IP is going to get load balances across those 4 instances, and I have sort of like a debug console here for each of these, so if I've got a lot of interprocess—inter role communication and other things going on, I can spew debug to these Windows and try to understand what's going on if something strange is happening. So that's what's kind of cool about being able to run that on your local machine, and then the other part is simulating the storage API's. All right so what to take away from this. It's really no different than building a normal application in terms of getting it configured except for just starting with the cloud service project. Now you can do something else, which is you can create a cloud service in Visual Studio, and then you can add to it an existing project application, so you don't need to do it exactly the way I did, which is create a fresh one. You can add an existing web app, and your existing web app needs to behave itself a little bit, and we'll talk a little bit more about what I mean by that. There are some specific concepts. But let's look at a slightly more advanced app that uses some more of the capabilities of cloud services. So let's just close this guy and open this guy. So let's run it first. You'll notice that this app has a Web Role and a Worker Role in it, and we'll take a look at both of those pieces. The only thing is when you're doing your debug and your F5 all the time, it does take a little bit longer to start when you're running in the Azure Emulator, because it actually has to deploy the app to Windows Azure Emulator and have it start up. It starts a lot quicker than it used to, but it still takes a little bit of extra time. All right, so we have a very simple Guestbook app here, very simply form on it, and I'll show you what it does. It's really not complicated. So I'm going to sign the guestbook, and I'll put a picture in there, and I'll sign it. Now you'll notice—I'm uploading a picture, and you'll notice what happens is when the picture gets initially uploaded, it's a pretty big picture. JavaScript error? Let's try this one more time. Let's do a fresh build. Now let's try that again. Okay, so there's this big picture here which for some reason the picture's not rendering all the way, but upload the picture, and it's really huge and ridiculous, and you'll see in just a few moments here if everything is working properly that I have an asynchronous process running in a Worker Role. It's out sniffing my storage account for guestbook entries that just arrived, and it's going to grab the image and actually make a thumbnail out of it and then republish it back into the course. I can actually run this thing from the cloud. Let's just quit messing around here. So I have a version of this app running in the cloud that's pointing to the same storage account in the cloud. So all it does is take that image, uploads it, puts a message on a messaging queue through simple API call, which I'll show you, and then I have that worker role that's just spinning that continuous loop. The worker role's only job is to go check that queue and see if there's any work to be done. If there's work to be done, it goes over and grabs the image and makes a thumbnail out of it, and then changes the pointer. I can real easily add a few more and hopefully it'll work a little bit quicker this time. It's going and picking up that queue, resizing, and then there's actually long polling going on in the client. You see that? How it just automatically refreshes long polling going on to check the image, and then it grabs a new one. Very simple app, nothing exciting, super ugly UI. My apologies for that, but it serves a point, which is it's super easy to get that kind of asynchronous capability to your apps. So I remember the days of doing password resets, where you would click "Reset my password," and then the thing would spin for, like, 30 seconds while something was going on, which is kind of silly now. With this capability, I could easily just add a worker role and use a queue and say, "Hey, Windows Azure queues, "go reset this person's password and send them an email when you get around to it," and then the UI will come back—it won't block. It comes right back to the user and says, "Your password will be sent to you momentarily." And that worker role comes and picks it off the queue and does something with it. It's a very simple construct, and it used to be kind of complicated, because you had to go write to Windows services, and how many folks have written Windows services? It can be painful at times. With this worker role construct effectively I have one file here when I create a worker role. It's called workerrole.cs, and in there I have this wow true, and it just loops forever, and I can do whatever I want in there. So let's look at what actually happens when we upload something to the web app. The first thing that I'm doing when I save that guestbook entry is I'm going to upload the image to my storage account. In this case, I'm using Windows Azure Blob Storage. With just a few lines of code, basically I can create a new blob and upload from the stream to blob storage, so that's 5 lines of code to do that. In this case, I have it configured just pointed directly to my cloud storage account. I can also emulate this locally and store these things locally, but I'm actually just pointing them out to the cloud storage account. The second thing I'm doing is creating a guestbook entry here, and this is using Windows Azure Tables, so this is a key value service that I talked about, and the third thing is I'm putting a message on the queue with the data about the guestbook person that just entered their entry. It's really simple, a few lines of code, a lot less than doing something with relational database, probably, and now there's something sitting on the code, so now there's an image in blob storage, there's an entry with other metadata in table storage, and there's something in the queue, so there's 3 different Windows Azure services available to you in storage system. They're available over the simple API's. Now let's look at the worker role and see what the worker role does. So the worker role basically comes in and says, "Get a message of the queue," and there is some other code down here, which will actually dequeue the message. Then basically parse it, so there's multiple different parts to be put into that message. You can construct the message however you want and basically serialize an object into that queue message. You can do lots of different things. In this case, it's a pretty simple structure, so we basically parse that queue message back into its components so we know what to do, and then we go and we process the actual code to do the thumbnail resizing, and then this thing just goes down here, and it sleeps, so it just sleeps for 10 seconds— this wow loop thread, and then it wakes up again and checks the queue again. Anything for me now? If not, it goes back to sleep and just does that over and over and over again. You can put a bunch of different code in here that does a bunch of different things every 10 seconds or every 20 seconds. You can split it out into multiple worker roles doing different jobs if the load is pretty heavy, and you know it's not all going to be able to be done by 1 moderately sized virtual machine. The other thing is you can change the size of the underlying VM that is actually running your Web Role or your worker role. You can make them huge with 12 gigs of RAM and multiple cores, or you can make them really small with 1 core and a gig or 2 of RAM. You have the control. And then of course you're paying based on what size of virtual machine you're consuming and how many of them, but it's all controllable. So let's flip back over here for a few minutes. So it's pretty easy to get started, do some simple things like that using cloud services— oh, what I didn't show you was deployment. I'm sorry! Let me flip back over and do the deployment. So once I'm ready to actually publish this thing, all I do is I right click on the cloud one, the one with the little cloud here, which is the configuration data, and I want to publish that thing, and I'm going to go back here, because I want to actually— let's say "New." So what you actually do is you download from the Windows Azure portal your publish settings, and I'm going to try to do that. So what you do is you click on that little link there and you get this file from Windows Azure that contains your publish settings. This is all the information that Visual Studio needs to connect to your account, your subscription, and start publishing services, so I'm just going to download this file to my local machine, and then I go back into Visual Studio, and I say "Import" and the one I just downloaded was that one. I have multiple subscriptions in Windows Azure under that same account. So I pick the one that I want, and then I just click "Next," and I pick the cloud service that I want to publish this to. Now I haven't created the cloud service yet, so I'm going to actually create one by selecting the dropdown. So while that's going, let me hop over here and say— I could have gone in here and created a cloud service before, so this is the Windows Azure Portal, if you haven't seen it. On the left hand side are all the different services that are available to you. If I want a new cloud service, I simply click on the Cloud Service tab, say "New." It figures out I probably want a compute thingy, and I probably want a cloud service, and then I can just give it a name. It figured that out, because I was on the Cloud Services tab. I could select something else and go create a database if I wanted to. It is just trying to guess what I want, because that's the tab I was on. So now let's create this thing, and then I can decide where I actually want to deploy that, so as I mentioned, there's multiple datacenters around the world. You get to choose where your thing is deployed. You're going to want it close to your customers, of course. You can also deploy to multiple datacenters and then set up traffic load balancing over the top of those in some more complicated scenarios. In this case, I'm just going to deploy to central U.S. I'm going to set up cloud services in central U.S., so when I deploy, it will go to central U.S. So the cloud service is created. That doesn't take a lot. Again it's just a container, so now if I can go back here— I need to refresh this because now I actually have a cloud service there that I want to use. I'm just going to cancel out of this and redo it. Cloud service thingy—that's the one I just created. When I publish, I want it to just go right into production who needs testing. Let's just go for it. Then I click "Publish." It runs another build, runs a test if I have anything configured, packages up that service package and uploads it to Windows Azure. As soon as the service is configured, you can see a little log of what's going on. It's uploading the package now. It uploads the package into a storage account and then tells Windows Azure, "Hey, there's a package over here for you to go pick up." Windows Azure picks that up, starts provisioning the infrastructure, and off you go. It takes about 5 minutes to deploy a cloud service, so it's one of the key differentiators between the cloud service model and the web site model. When you deploy the web sites, it's instantaneous. When you deploy to cloud services, because it's actually going and building fresh VM's for you under the covers, it takes a little while longer. Web Sites actually has warm VM's ready to go that it just pulls into the equation, so it's a little bit of a different model, and the reason for that is because with cloud services, you can have your own startup scripts that configure any number of different things, whereas with Web Sites, you just get IIS, and you get a couple of other run times and that's it. You don't have any control over that stuff, so that's the trade-off that you make there. Yes, sir? (off-mic question from audience) [Craig Kitterman] You mean when you're deploying in the staging versus production? (off-mic question from audience) [Craig Kitterman] Yes. (off-mic question from audience) [Craig Kitterman] Oh, good question. Yeah, so we do— it will go offline once the new one comes on, yes. It's basically what's called a rolling update, and say you have 4 instances of your old one running, it'll update one and then update the next one and then update the next one and the like, and the sessions that were already in flight will continue until the new ones are all there. Yes, sir? (off-mic question from audience) [Craig Kitterman] No, it's using a proprietary software load balancing schema. (off-mic question from audience) [Craig Kitterman] I don't think that the load balancing stuff would be part of that alignment. I don't think it is. That would be pretty unique, so I don't think so. Yes, sir? (off-mic question from audience) [Craig Kitterman] Great question—so the question is, how would this work with an Oracle database? If I understand correctly— the other thing that I didn't mention about this cloud service model is that because Windows Azure now has infrastructure as a service, you can go provision arbitrary VM's to do whatever you want. You can go create a Web Role and a worker role in the platform as a service model and still have other applications like Oracle running in a virtual machine that the app talks to, just like you do today, so it would be distinct. You wouldn't do anything with Oracle in this model. You would probably just run it in a VM. You wouldn't try to set up a startup script to deal with Oracle. That'd be really square peg, round hole type scenario. I would just run the Oracle in a virtual machine, and then do your presentation tier or your API tier, whatever in cloud services, and then you can talk to that database. (off-mic question from audience) [Craig Kitterman] Oh, if there's Oracle dll—are they managed dll that run in clr? Then yeah. (off-mic question from audience) [Craig Kitterman] Okay, yeah. So you could set up a startup script to configure and appropriately install your dll and make them available. You could do that. Sorry I misunderstood that question. Okay, so it looks like the things up. Let's cross our fingers here. It says it's inan "unknown state." I think it's still deploying. So anyway, it's that easy to deploy from Visual Studio and then once everything is up here— you can see it's deploying right now. Starting the VM's, and you can see I have 2. I have a Web Role and a worker role that are starting up right now. Some instances are ready, some are starting; sometimes it takes a little while. So let's go back over here. All right. Now I mentioned earlier if you're going to go create a cloud service project, and you're going to add some old app to it, you want to make sure your app behaves, and what I mean by that is, is your app really designed for the cloud? When I drag that slider bar out to 92 to scale up all this infrastructure, is your app going to actually behave—work the way you expect it to work when all the sudden the traffic's being load balanced across all these instances? That is the question. So designing cloud apps is a little bit different, and I want to take you through some of the core concepts there. Rule number 1: Design for scale. I'm pretty sure the manufacturer of that train didn't have that in mind when they built it. (audience laughs) So anything can happen, right? (off-mic question from audience) [Craig Kitterman] I believe so, yeah. (laughs) So somehow it still works. I don't know how, but you need to think about not just how your business behaves today and how your customers behave and what your expectations are, what what can happen in the future if you're wildly successful beyond your imagination. Just take some simple steps in your architecture to make sure that that's ready. What that means is building your app to be completely stateless. These are stateless VM's in the cloud. They don't persist anything to the disk, so if you write something to the C drive, when that hard drive fails eventually, which is will, and Windows Azure goes and provisions a new one automatically, it doesn't know what you wrote to the C drive on that virtual machine that's now gone away, because that storage is not persistent. So what this means is when you're doing things like storage, you're making sure that that data is persisted into a storage service that is available from all the instances of your app. In fact, there's no guarantee that when a user gets assigned to one instance of your app from the load balancer that the next request from that same user is going to get assigned to the same VM. It might actually get bounced over to another one, because maybe some weird failure happened in the middle. You don't want any state on that virtual machine that your user requires to continue their transaction, and so that also means things like session state. You can't store session state and memory on the machine anymore. You need to use a cache. You can use one of the caching models that I described earlier. You can use database for session state, if you want to—there's a few different options there, but you can't store on the local machine, because even though your app might look like it's running fine and it might test fine and everything else, at a certain point when something weird happens—or unexpected that session's going to get blown away, and your user's going to be back to square one, and their shopping cart is going to go to zero, and you're going to lose that sale. So don't do that. Last Christmas or a couple of Christmases ago— I think it was a year and a half ago. We're all sitting at home, watching our favorite Christmas movies. This one is mine. And then this happened. Oops! It made big news. When Twitter goes down, you get the—oh, it's Tuesday, right? When Netflix goes down, people get pissed! That's serious! Netflix doesn't go down! It can't! So it made big news. This is a big deal, right? Failure happens. In fact, in the cloud—is designed— the cloud is built with that in mind. When I think about the way that our infrastructure in Windows Azure is designed, it's commodity-type infrastructure that has failure rates that are non-trivial. Hard drives fail, network switches fail, power transformers blow up, things happen. It will happen, guaranteed. You have to keep that in mind. You have to design for failure. That means using things like geo-redundancy in your storage schema. No single points of failure in your application, because sooner or later those things will happen. The great thing about the cloud and platform as a service in particular is all the tools are there for you to use— all those API's, geo-redundancy in storage. In Windows Azure, if you want your— your data is automatically replicated, by the way, in 3 places in a single datacenter. So if 1 hard drive goes down or one of those containers blows up, your data's in 2 other places in that same datacenter, and with a click of the checkbox, it will automatically be geo-replicated to another datacenter more than 500 miles away, in case of a disaster or something. So there's tools there. Use those tools. Implement those tools. Understand how they work. Understand how if something does happen, get your data back, because sooner or later, something strange is going to happen. Yes, sir? (off-mic question from audience) [Craig Kitterman] In most cases, yes it is. That's kind of the core tenant. Although strange things have happened before. Obviously we try to keep those to a minimum. Those services are designed to be fail over, geo-redundant, all of those things. You should be able to trust in those API services. That's a great question. Thank you. Netflix is even the poster child for designing for failure. They have this awesome thing called chaos monkey. Have you guys heard of chaos monkey? It's this of software that they unleash upon all the Netflix infrastructure, which happens to be running on Amazon AWS to just go randomly break stuff, and they randomly break stuff in production, because the only way to really know what's going to happen if something breaks in production is to break it in production and see what happens, and if it goes down, go fix it and build more resiliency into that model. They've done a really, really, really good job of building for redundancy. That's why Netflix almost never goes down. This was a freak occurrence when it went down, but they really do a really good job with that. Look at what they've done— I think they've open sourced a lot of the libraries and intellectual properties associated with their chaos monkey methodology. You can go look at that and see what they've done. If you're building serious enterprise grade apps, you want to be thinking about those types of things and stand on the shoulders of of giants who've already figured out how to do this stuff and go use it—go use those libraries. I don't know how they work, but I know they're out there. You can build a system that is pretty darn close to 100% reliable. This kind of goes back to your question, sir, which is I can have everything triplicate, quadruplicate, redundant everywhere, but the cost just starts to get astronomical. The more nines you add down there— for every 9, you probably double the cost associated with running that application and managing that application. So you really have to think about what is your business asking of you in terms of service level, and then architect your app smartly. One way to do that is decompose by workload. Your app typically does different things. In the case of our silly little guestbook here, one part of the app served up a presentation tier where I entered in some data and saved a file, and another part of the app came up and created thumbnails. In a real business scenario, piece A and piece B probably aren't equivalent in terms of their value to the business. Maybe piece A can never go down. The web site can never go down. But the thing that creates the thumbnail— it's like who cares when that thing runs—if it runs in the middle of the night or whenever. People aren't waiting around for their thumbnail to be created, except for me. So how do you decompose the workload and think about, "How do I deliver the SLA "I need for component A "and then maybe do something a little bit cheaper where I don't need that type of service level?" So one example would be if you had a sports API, and people hit the sports API to get the latest and greatest scores and updates. Well during the game, the SLA for that thing is pretty darn close to 100%, right? That cannot go down during a game for live scores and commentary, because people are watching real-time like, "Oh, my gosh, what's going on with my team?" So that thing has to be up. But when there's no game, live scores and commentary doesn't mean anything, because there's no game. It literally can go to zero. All the rest of the time, like basic team player league stats— those things need to be 100%. If you can kind of tease apart and break those things down, it makes it a lot easier to architect your app smartly, so you're taking advantage of the redundancy and the fail over capabilities, but only paying appropriately—what the heck was that? My timer? (bell sounding) How do I turn it off? It's okay? (laughs) Scared me! Rule number 4—we're almost done! Design for interoperability. You never know what's going to happen tomorrow. Same with the scalability story, you don't ever know what applications are going to want to consume data from this application, what new types of devices are going to get in tomorrow. You have to think about future proofing your apps and your data and design for interoperability. This is true universally, but particularly in the cloud, because everything is becoming more accessible, more programmable, and you want to make sure that you're future proofing those assets and creating open API endpoints for things and being smart about not locking into a particular architecture with particularly the data. Last but not least: Design for operations. You can only improve your application if you know what's going on. Instrument that thing, use all the tools that are out there. Great stuff like at the APM's New Relic, some of the other monitoring tools in the Azure portal, stuff like system center— understand what's going on inside your application, so you can tune that thing, and it takes a little bit of work on the dev side to do some instrumentation there, but it's going to make life easier for you. It's going to make life easier for your ops folks. Particularly in the cloud, when you're not running that server, and it's running out somewhere else, you've got to see into that app, so instrument for ops and design for ops. Those are kind of the key rules. So let's do a Q&A. Yes, sir? (off-mic question from audience) [Craig Kitterman] The question is, does Windows Azure support multi-tier applications that use Windows authentication? The answer is yes. That's a pretty regular scenario that we do. Yes, sir? (off-mic question from audience) [Craig Kitterman] That's a great question. (off-mic question from audience) [Craig Kitterman] It does, except for— it's probably using a lot of the same resources, not spinning up the equivalent of a whole virtual machine. It's using the same underlying resources and the same CPU, the same RAM or whatever. So yes, but not as much as if you were (coughing)— not as much as if you were actually spinning up VM's. Nowhere near the same. Yes, sir? (off-mic question from audience) [Craig Kitterman] Oh, I'm sorry. Let's take a look at that. How do you choose the size of VM's that you are going to use here? Sorry, it's somewhere in here. Let me find it. Let me show you that after the talk. It's in one of these config. It's in the—no, it's actually in the configuration for the actual service here—the app. Sorry—let me find that after. I'm sorry. I should have shown that. I forgot to look that up. Other questions? Yes. (off-mic question from audience) [Craig Kitterman] For Web Site—for just simple web sites? (off-mic question from audience) [Craig Kitterman] Yeah, I think so—I don't know what you're paying, but we have a pretty competitive offer, particularly on the web site stuff. We have a free tier. We have also a reserved tier where you can run up to 100 web sites on shared resources that's really competitive. So I can show you what those offers look like after, but we didn't get a response—people are using it, so they must be seeing price value there. Good question. Yes, sir? (off-mic question from audience) [Craig Kitterman] Oh, good question. So on SQL server— the way the SQL database service works— if you're using the platform as a service, SQL service, which is called Windows Azure SQL Database, you don't specify the number of instances. You simply specify that you want this type of database and it gives you an endpoint. It handles all that stuff sort of under the cover, so it's a slightly different model from what you get today. (off-mic question from audience) [Craig Kitterman] Yeah unless you're using— (off-mic question from audience) [Craig Kitterman] You just provision more databases to do your sharding. You have to do that sort of manually, but that's effectively the way you would scale using SQL databases to do sharding and scale out. Yes, sir? (off-mic question from audience) [Craig Kitterman] Oh, good question. When you provision your cloud service, Windows Azure will assign you a DNS called whatever you ask and then you can go and do your DNS records or your C-names or whatever on top of that, but you get just a default DNS—it has to be unique. (off-mic question from audience) [Craig Kitterman] You go into your DNS records and create a C-name that maps from your URL—www.whatever to Yes, sir? (off-mic question from audience) [Craig Kitterman] There's all kinds of plans for better instrumentation across the board. That's all I can really tell you. Right now you can go in there, and you can set up New Relic or Adonomics and get richer real-time data than you can get in the portal, and they're free-tier. In the Windows Azure portal, you go to the store. You provision those things, and they have a free tier, which is pretty awesome, actually. We're always looking to get better, more dynamic, quicker information on all the key metrics, and we'll service more of that in the portal. I see something over there? (off-mic question from audience) [Craig Kitterman] Yeah. So you basically say extra-small, small, large, whatever. It's been awhile since I created a cloud service, because I've been using Web Sites, and now I can't remember where that is, so if anybody wants to see that, come up at the end, but it's just a simple drop-down box where I pick the size of the VM, and then that's going to have impact on what I what I end up paying. I have to figure it out. Yup? (off-mic question from audience) [Craig Kitterman] Great question. The question is, can you load balance between the cloud and your on-prem solution? Not with— we have a service called Traffic Manager, which allows you to load balance across deployments in different Windows Azure datacenters, but not today between Windows Azure and your on-premises environment. You may be able to get a third-party load balancing solution that can do that. I know you can, but you can't use ours to do that yet. (off-mic question from audience) [Craig Kitterman] I think so, yeah. So there are solutions to that, but unfortunately our Traffic Manager product doesn't handle that scenario yet. That's definitely a popular request. I hope we can do that some day. Yes, sir—right up front. (off-mic question from audience) [Craig Kitterman] For backup strategies via the cloud? There's tons of different options. One of the cooler things we did is acquired a company called StorSimple. Are you familiar with this company? Back in November—and they have this appliance that sits on your LAN and does some really intelligent caching with your data, so files that are accessed—it looks just like a SAN or whatever, and you just dump data to it, and then it starts putting things in the cloud as they get old, and then as you retrieve them, it brings them back down and does some cool stuff like that. (off-mic question from audience) [Craig Kitterman] Oh, I see. So if a user deletes it, you'd have to go through Windows Azure support and they'd have to go pull an old version for you, and I don't know how painful that is. It may be painful, which is different than— (off-mic question from audience) [Craig Kitterman] Yes, so what you do is you just create some kind of job that takes a snapshot of all your blobs and post them somewhere safe. There's API to do it. You could do it in a few lines of code practically, but it's just like any other production. You have a production storage account, which has the real images on it. If you want them backed up, you want to back them up somewhere else. Now if one day the center goes down, like I said, there's multiple copies of your data and Windows Azure will automatically restore your data back, but if some user deletes them, it's probably a more painful process to go through to get it back. In the back there, yeah? (off-mic question from audience) [Craig Kitterman] If you've got a multi-tier app, you can definitely scale the various tiers independently of one another. (off-mic question from audience) [Craig Kitterman] Great question. Can I automatically scale various tiers of my app when something happens with 1 tier? So what we've done is in the Windows Azure portal— and maybe I can show you at least the basic monitoring that you get here. I apologize for using Chrome, but my IE was having some weird network problem. In the dashboard here, you get some—that's the one I just provisioned, so it's not going to have much. Here's a VM that I had earlier, and you can see what you can get here. It's going to take awhile to load. So you get some basic data here in terms of CPU and RAM and other things that should show up on that graph, but this one hasn't been used much. The nice thing is that all of that data is available through API's, so you can instrument system center to respond to specific thresholds that you set. We have another piece of code that was put out by Microsoft Patterns and Practices, which is called Windows Azure Application Scaling Block. You can configure it in a number of different ways to set thresholds. If my CPU utilization goes above 65 all of my instances for more than 5 minutes, add another instance. If it drops below 20 for this amount of time, take 1 off. You can do that with every tier of your application. So you have full API program to control on both sucking the statistical data—performance data, as well as actually acting on that and doing some kind of scale out action. We are looking into making that more automated in the future, so you can do it directly from the Windows Azure portal rather than running separate pieces of code but nothing to say yet about that. (off-mic question from audience) [Craig Kitterman] I see what you're saying. That's a good question. I don't have an answer for that one. I'm sure there's a— the question was if there was a service attack, how do you make sure your autoscale doesn't scale to infinity, and then your credit card explodes in your pocket? Great question. I'm sure that there are some safeguards in place you can put, but I don't know what the things are there. I mean that's the important bit, right? Your site never goes down! Yes, sir? (off-mic question from audience) [Craig Kitterman] Oh, really? So what I would invite you to do, and I would invite everybody in the room, and I wish there were more people in the room still, but I guess that's my fault— is to come by the Windows Azure booth and what we have is a series of challenges where we're going to take you through 4 different challenges, if you will, to do different things on Windows Azure. There are people there to help you through that process, and you win a prize after you do each one, so the first one is go spin up a VM in Windows Azure. It's the easiest darn thing you ever did, and you get a water bottle. The next one is a little bit harder, and you get some headphones. Then at the end if you get all 4 of them, you get entered into the raffle for a Trek bike. So there's an active directory scenario down there. I invite you to come down, and the experts with the active directory service are down there and they can help you go through that process, and you can ask them all the questions you have. (off-mic question from audience) [Craig Kitterman] If I understood your question correctly, how do you manage the different configurations between running locally versus running live in the cloud? For managing things like session state? What's that? (off-mic question from audience) [Craig Kitterman] Exactly. You would pull out the 2 lines of code where you're writing the file to the disk, and instead you would write it to Windows Azure Blob Storage with 2 different lines of code. That's the main change that you would make in terms of things you would write to disk— you're going to want to write them to Blob Storage, and then all your instances are looking at the same blog storage account, and so they can see all that data, and going back to your question— you would have to have some kind of switcher code and you can have 2 separate configurations. You can have a cloud configuration file and a local configuration file, so you can say whether you're running locally on this environment— you can have 10 configuration files if you want. In this case use whatever, and then when I deploy the cloud, start using the shared cache role to store session state, and you just configure that. (off-mic question from audience) [Craig Kitterman] Yeah, it could. In fact, that's what I would recommend. I would recommend that. It's going to be faster for sure than a round trip to the database. All right, one more thing I want to remind everyone of before you leave is that if you're an MSDN subscriber, go activate your Windows Azure. You get lots of monetary credit now. It's a new system. It's really awesome. Scott talked about it this morning. I'm giving away an Aston Martin at the end of September, so every MSDN subscriber who activates their Windows Azure benefits and deploys something— you've got to deploy a VM or a web site, you're automatically entered into the sweepstakes for a 2013 Aston Martin V8 Vantage. Doesn't matter what it is, so try it! If you already have an account—great question. If you already have an account, you're still eligible. You already have an—sorry. You have to already have an MSDN subscription, and even if you've already activated your Azure before today, you're still eligible. You just have to deploy something between now and September 30. Yes? Official rules and regulations are at, so please check it out and click the "View Details." And with that, thank you very much, and I can take more questions off. [audience applause] Yes, sir? (off-mic question from audience) [Craig Kitterman] Yes. You can go now in your account and see real time what your accrual is. (off-mic question from audience) [Craig Kitterman] Yes. I should have mentioned that. Everything that's through the portal is available through API's and Powershell, and we have Powershell command to do everything—almost everything. (off-mic question from audience) [Craig Kitterman] This one? (off-mic question from audience) [Craig Kitterman] Are they just web and database, or are they connecting to other systems and applications? (off-mic question from audience) [Craig Kitterman] You should look at Windows Azure Web Sites if it's just web and some web services and a database, and it's not connecting back to lots of other systems. Over HTTP?

Video Details

Duration: 1 hour, 16 minutes and 8 seconds
Country: United States
Language: English
License: All rights reserved
Genre: None
Views: 6
Posted by: asoboleva99 on Jun 28, 2013

So you're a Microsoft .NET developer who is ready to see what cloud has to offer. Come take a peek at Windows Azure Cloud Services, the fastest and most productive way to capture the benefits of cloud without leaving .NET and Microsoft Visual Studio—and without calling your IT department!

Caption and Translate

    Sign In/Register for Dotsub to translate this video.