March 24, 2009 Leave a comment
March 19, 2009 Leave a comment
Yeah, finally the information you’ve been waiting for. Sorry its late. I’d like to say it was due to the 22hr outage Windows Azure suffered over the weekend, but that would be a bit of a fib. So lets just say I have a busy social life. At least that is a lie big enough to be worth telling. For this walkthrough, I’m assuming you already have the SDK and project templates installed. If you don’t, then stop reading and go get them.
Back? ok, here we go.
Fire up VS08 and go to the file –> new –> project menu to open the “New Project” dialog box. Next select the Could Service category. You should see the following projects listed…
The one we’re going to talk about today is the Web Cloud Service. As you may recall, an Azure Web Role application allows for inbound as well as outbound connections whereas a Worker Role only allows for outbound. I want to start with the Web role since this one will be most like traditional .NET web development. Select the “Web Cloud Service” template, give it a name, and click “OK” to create a sample project.
The image to the left shows the solution explorer for the newly created project. Notice that there are two projects in the solution. The bottom project, WebNotepad1_WebRole looks much like a typical web application. We have references, properties, a default page, and a Web.config file. The list of references is the only quickly noticeable difference.
The top project however, is a different story. WebNotePad1 is a Cloud Service Project (extension ccproj). Unlike the previous project which was a straight up web project, this is a new Azure specific project. This project is required if we want to debug, run, or publish our project. If you don’t see this project, you may have created a web role project by mistake. If that’s the case, you can create a new Blank Cloud Service project and simply add your web role to it. Easily mended.
There’s a considerable amount that can be done with the configuration files in this project, enough to fill a chapter in a book someone, somewhere is already writing. So I’m just going to touch on a couple things here. There’s two configuration files in here. ServiceConfiguration, and ServiceDefintion. These files are just what they say they are. The definition file describes the contents of the configuration file. The configuration file tells the Azure fabric how your application runs (for example,the number of instances of each role to run). It can be updated on the fly once the application has been deployed. The definition on the other hand cannot be updated without restarting your application. I’ll try to get more into these and managing your published application at a later date.
That aside, lets open up the Default.aspx file of the WebNotepad1_WebRole project and put some custom text into it. “Hello world” has been done to death so I prefer something more likely to engender world peace. You can put in whatever you like and press F5 to start debugging your new cloud application. Now the magic starts to happen. The Development Fabric starts up and using the cscfg file mentioned earlier, a instance of our web app is powered up and deployed. If this is the first time you’ve started the development fabric, you’re also going to be prompted to configure Development Storage. I’ll touch on storage another day, so just take the defaults so that our page starts running.
After a few moments/minutes, a web browser should appear and display our page. Things may look similar to this screen shot.
The URL of the displayed web page makes it pretty clear that this is running locally. As I previously mentioned, its running in the local instance of the Windows Azure Fabric, the Development Fabric. If you look down the task bar, you’ll even find the running instance of the Dev Fabric as an icon (see the notes on the above screen shot). Double-click on that icon to open up the Development Fabric console. The Dev Fabric console allows us to manage what is going on with each instance of our Azure applications. Using this, we can see each instance of the app (if we had more than one running), as well as any messages being output by that process to the console. We can start/stop those instances, and even make manual changes to the configuration.
So we’ve started a new project, and gotten it running locally. Yeah us! Now buckaroos, its time to take it to the next level and unleash this little monster on an unsuspecting populace. We’re going to publish our application to the cloud. We’ll start by logging into the Windows Azure portal and creating a hosted services project (go to lx.azure.microsoft.com and after logging in, click on the “new project” link). What we need from this, is the Application ID and Return URL.
Now we associate our application with the assigned ID by right clicking on the Cloud Services project (this is the one that contains our csdef and cscfg files), and selecting properties. In the properties area, select the Portal tab and enter in the assigned Application ID. Now save the project, then right click it again and select “Publish”. This will “build” our Cloud Services project, creating a deployment package and associated configuration file. These artifacts can then be uploaded to Windows Azure for deployment by the fabric.
There’s a considerable amount of automation magic going on here. But the important thing is to see that the pieces are starting to come together. Our Web Role project is compiled, then a Windows Azure specific deployment package is created for it via the Cloud Service project (this results in a copy of our cscfg and a cspkg (cloud service package) deployment package). When this build is complete, two windows will open, an explorer window to the location of our files on disc, and a web browser so we can log into the Azure portal and deploy our application into the cloud. Log into the portal and click on the “Deploy” button. We can now select our two files, give this deployment a name, and upload… er DEPLOY!
This is where the Azure Fabric really starts doing its work. It brings in my package and its configuration file. It then looks for a VM instance it can use for my application, configures it appropriately, and installs the application (and any dependent bits into the cloud for me). Depending on the size/complexity, this can take several minutes. Once that’s done, we’re ready to start the application and preview it. So click on the “Run” button and when its complete (watch the status of the WebRole, make sure its “Started” and not “Initializing”), click on the provided Web Site URL to preview the application. Starting the application can take longer then deployment did. Its during this startup that the VM instance is actually spun up and made ready for use.
At this point, the application is live, and ready to be used. However, its not in the final production location. Its always important to test an application in an environment that matches its final production environment as closely as possible. And while the Development Fabric does its best, there’s just no substitute for running in the cloud. To that end, Windows Azure allows for a two stage deployment, staging and production. After our first deployment, the application sits in the Staging Environment and is given a URL that uses a randomly assigned GUID. This GUID helps hide it from anyone else on the internet and gives us an opportunity to test the application privately. Once we’re certain the application is working, we can then click on the promote icon (its a yin/yang symbol between our environments) to promote it to production.
And there you have, it, your first Windows Azure web cloud service. If you are truely bored, you can check out this sample application at: http://brentnotepad.cloudapp.net/
In my next post, I’m going to test the waters with the Windows Azure’s local storage. In preparation, I’ve started forgetting everything I’ve ever learned about relational databases.
March 13, 2009 Leave a comment
March 10, 2009 Leave a comment
Well, I got my PC rebuilt, and outside of a few files I thought I had backed up I have the bulk of my stuff back. I’m thinking I may try leveraging Live Mesh a bit to see how it does for helping make sure I have redundant copies of some of my files. But that’s for another day…
I’ve been percolating thoughts about how Azure will compare against other cloud vendors such as Amazon, Google, and SalesForce. While I’m fully on the Azure bandwagon, at some point and soon I’m going to need to be able to speak to the capabilities of the other platforms and contrast/compare then for clients. To that end I’ve been doing some new searches and ran across the link below…
Mr. Miller does a good job of giving a 10,000 foot overview of the “big three”. He’s got a couple points wrong on Azure… but given that he wrote article shortly after the last PDC I’m happy to cut him some slack. Especially with some of the time he’s saved me pulling that article together.
In a nutshell, Amazon will give you greater platform and application options, but Azure gives you a natural extension to your current VS development experience and offers load balancing and scaling out of the box. Google is the most restrictive of the three, but may have the edge on overall capacity, at least in the short term. I think the real deciding factor here is Microsoft’s approach of Software + Services. They’re not talking about just doing applications in the cloud. They’re really focused on using the cloud for both new application development and as a way to help extend applications by combining them with services (as touched on in my last posting).
This goal, to help enable organizations to take advantage of more options, in new ways will be the real differentiator IMHO. I can already see my client technical demos calling this out and making it a centerpiece. I also believe that focusing on this aspect, the extension and enhancement of applications will be a key selling point for enterprise clients who are used to holding their datacenters more tightly.
March 5, 2009 1 Comment
March 3, 2009 Leave a comment