On Premise Windows Azure – Not likely


I’ve heard this question and seen this message posted several times. But it bears restating… Azure requires such a customized setup that its simply not feasible (currently) for internal implementation. I do NOT believe that this kills Azure’s viability. I believe that there are as many potential clients for this as there are hosted services. Lastly, I believe that we likely haven’t heard the end of this.
Folks that believe Azure’s lack of on-premise support destroys its viability subscribe to the "all of nothing" school of thought on SaaS. As I’ve mentioned before, SaaS is an enabling technology. Or as I put it to another person, SaaS is a box of crayons, one of the nice big "deluxe 64" boxes. When you’re creating a picture, you don’t need the whole box. You pick and chose the colors that allow you to best realize your vision.
I’ve also seen folks question who would want soemthing like Azure on-premise. Wouldn’t this go against the idea of putting things in the cloud? I’ve known several organizations that manage their own datacenters that would love to have something like the Azure fabric to help reduce infrastructure costs and increase availability. With the increase emphasis on virtualization within the entireprise, a product like Azure with its dynamic configuration and potential for scalability would be a huge boost to those models. Why wouldn’t a sufficiently large organization want it?
Lastly, I honestly don’t think we’ve seen the end of this line of thought. Will we see an on-premise Windows Azure in the next 2 years? unlikely. Will it even be a strictly OS based package that you buy and just install on your own hardware? I doubt it. But I can see a joint hardware/software vendor selling pre-configured cabineets that could be placed into an existing datacenter. This would only be an incremental step from several products that are already on the market. However, like those solutions, this option would likely prove to be expensive enough to put it out of reach of many organizations.
But then these are only my opinions. Open-mouthed

Azure Tools/SDK Updated for March 2009

Get the latest update here.
Highlights include:
  • single installer for tools and SDK
  • FastCGI project template (for thigs like PHP)
  • Update notification
  • various bug fixes

Hands on with Azure Web Roles

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…

project templates

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.

solution explorer

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.

Running Fabric

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 CloudNodePropertiesthe 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. 🙂

SQL Data Services – Update

I’m still putting together my first Azure post that dives into a project. I have a list of about 6 or so topics that post will touch on and I’m even going to try and include a few screen shots. Its likely to be my biggest post to date, so please bear with me a little longer. That article will finally get into the hands on stuff you may have been coming here hoping to find.
Meanwhile, I do have a new link for you today. Evidently the first real news on Azure’s SQL Data Service is breaking. I haven’t even had time to start digesting it all myself yet. So rather them to just quoting what others have already written, please click the following link and read for yourself: http://blogs.msdn.com/ssds/

Azure, Google, and Amazon

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.

Azure Tangent – some folks are missing the point

So as I continue on my journey of learning Azure and the broader topic of could computing, I’ve noticed that it appears some folks still don’t get it. I’ve seen, several times I might add, folks asking questions like "but I can’t put xxx into the could for reason yyy". Its important to point out that these folks are still thinking old-school.
Doing work in the cloud does NOT mean that everything needs to live in the cloud. The cloud is just another option, an enabling technology. Part of the promise of cloud computing is that you can bring together different components and combine them into a new solution. You can take bits of virtual earth, combine it with say CRM Online Services, use your own AD as a security authority, and mash it all up using your own internal data. The only part of all this that may exist as your own cloud application is the presentation layer. The virtual earth bits aren’t part of your cloud, they exist in their own container. The same could be said of say… your data. It may still reside within your network, on a database server you manage. You just expose the information you need to your cloud application, possibly via a secure connection, or more likely as a series of web services.
This type of application mash-up is already being done all over the web. We just need to start thinking outside of the box and realizing that the cloud can be just anotehr extension of the environments we’re used to working in. The best example I’ve personally talked with of cloud was using it to deliver a solution that had to cross data-center boundaries. They didn’t view the cloud as a replacement for the datacenters, it was simply an extension of their infrastructure that provided an easy way to cross their current boundaries.
I guess the point I’m trying to make, and the one I think some folks are missing, is that Windows Azure isn’t where everything should live. Its simply another option for enabling your organizaing to meet business needs. Will it be appropriate for everyone? No. But it can and does give businesses of all sizes new tools they can use when delivering solutions.

Azure’s Fabric

Sorry for the delay. Between the demands of family and a dead hard-drive, I’ve been a bit busy. Last time we did a high level overview of the components of Azure Services. This time I want to look a bit more closely at just Windows Azure, the operating system used by customer applications.
While development for Windows Azure is .NET development, it is not the same as development targeting any other Microsoft platform. Neither is the way in which these applications are hosted. In a nutshell, each application that is deployed into Windows Azure is given its own dedicated virtual machine instance. This VM instance is in turn bound to a single processor core that only handles processing for that VM. These VM’s are managed by the Azure’s Fabric.
The Fabric is not only a glue for Windows Azure, its also a baby sitter and mechanic. It watches over all the VM’s and makes sure they’re running well. Azure Fabric also handles deployment of applications and upgrades to the VM’s. When a new application is deployed into Windows Azure, the Fabric will look an available VM, upgrade/patch it if necessary, configure it based on the type of application, install the application, and start it running. Think of the Fabric as your own personal SCM team. Only the Fabric doesn’t need smoke breaks or a coffee machine.
Now, for obvious security reason, you can’t attach a debugger to an application that is running in the cloud. So when doing your development and debugging, you’re going to want to do as much of it locally as you can. To do this, your of course going to need a local version of the Fabric to run your applications in. The Azure Development Fabric is where local applications will be deployed, spun up by Visual Studio when you press the debug button. Just keep in mind that this local “emulator” (for lack of a better term) may not always behave exactly like the real thing. So while local debugging is helpful, final testing should still be performed once the application has been deployed into the cloud.
Last topic for today is something I touched on a a couple paragraphs ago… The Fabric will configure the the virtual machines based on the type of application you are deploying. In Windows Azure, there are currently two applications types, called roles, that are supported. The Web Role is an ASP.NET based application. It can be a web service or public facing web page. An application built on the Worker Role is more like an NT Service. It runs continually, great for long running processes. A key difference between these two roles is that the web role can accept inbound communications whereas the Worker Role cannot. The Worker Role can call out, but can’t be called too. Communications to a Worker Role application can be done via the topic of our my next post, Azure Storage.