As I spend more time with the CTP I will be posting more detailed, in-depth walkthroughs of the technologies as well as code samples (hopefully I'll get approved for my Azure hosting account soon *hint* *nudge* *wink*!!). For now, I'm just going to do a high-level breeze-by of the main aspects of Azure.

Windows Azure

Put simply - Windows Azure is a technology that will allow developers to build applications in the cloud. The GUI for the application is in the cloud, the back-end processes that are running are running in the cloud, and the central data store for the application is in the cloud. The great part about this is that you can run it all locally, test it, play with it and vet it. Then you can upgrade it so it's running locally but using cloud storage. When you're finally set that your app is ready for primetime, you can push the app to the cloud and continue using cloud storage. 

On a lower level, Windows Azure allows you to build and publish these things called Web Roles and Worker Roles. A Web Role is nothing more than a bunch of code that has been bundled up and pushed into the cloud that responds to HTTP(S) requests. These Web Roles, at least in this CTP, are ASP.NET applications but it looks as though you'll be able to do Ruby on Rails, PHP (god forbid), Python, or whatever you like. I'm hoping for a VS 2008 plugin that lets me build ASP.NET MVC Beta 1 apps that can be published as Azure Web Roles. A Worker Role is a piece of .NET code that is running in the background.

Traditionally one of the biggest problems people have, from hobbyists to developers for huge corporations, is that external hosting facilities only work well if your ASP.NET app is 100% self-contained and requires no additional services and no background processing, etc. Windows Azure lets you develop apps in cloud AND push your services into the cloud AND store your data in the cloud. Keep in mind that a Silverlight application counts as a web application ;) Starting to see the possibilities here?

.NET Services

Apple's MobileMe slogan was at one point "Exchange for the rest of us". .NET Services can be thought of as "Biztalk Services (in the cloud) for the rest of us". The bottom line is that .NET Services are a cloud-centric way of solving many of the problems of distributed applications. There are three main pieces of .NET Services:

• Access Control
• Service Bus
• Workflow

While access control is certainly nice, and it is done using tokens and claims (more on that in another blog post... tokens, STS, claims, and authentication is a pretty dry topic and needs a good sample when talking around it), the thing that interests me here the most is the Service Bus. The Service Bus allows you to create these publicly exposed endpoint URIs for services. You can then host that service from some application on some desktop. Any client that knows the public URI for that service can then connect to that desktop application and consume the service - regardless of whether that client is on a 10.* or 192.168.* subnet, behind firewalls, in a Starbucks, or whatever. The "cloud" is providing a relay service through which clients in a distributed application can communicate with each other. One of the relay types that I am REALLY looking forward to experimenting with is the P2P relay, which I would assume allows me to have a globally registered peer mesh, allowing all of my app clients to talk to each other, no matter where they are in the world (note: this assertion has yet to be proved, I'm just dreaming big at this point). Workflow is also pretty big if you've been using WF now. Think of this as the WF integration that BizTalk was going to get, but plugged into the cloud.

SQL Services

I'm sure a lot of data guys are going to be pretty excited about this, but for me it's pretty straightforward. SQL data (in a slightly different shape and form than if you were storing it in your own SQL 2008 Server in your enterprise) in the cloud. I can imagine big concerns around privacy, encryption, and reliability will crop up around SQL services in the cloud.

Live Services

Live Services isn't really all that new, they're just being re-branded underneath the Azure umbrella. This is all of the goodies that you get with the Live APIs like contacts, calendars, e-mail, identity, etc.

Summary and Vision

So..what does all this stuff mean anyway? What's in it for you? In the short term what it means is that developers are going to start finding that they have been given a ridiculous amount of power. This is more than just Microsoft hosting your code in some central data centers... This is Microsoft abstracting away the notions of data centers, virtual machines, or even physical CPU cores (well, that abstraction is coming later). If you want to build an internet application, and you want to build it quickly and easily and you know that your app needs to run "out there", and you don't have the resources to do it yourself, or have your own data center, then you're going to find that Azure may just be that enabling force that we've all been missing for so long.

Windows Azure's concepts of Web Role and Worker Role is absolutely, totally, and unequivocably a game-changer in the world of cloud computing. The best thing we've had prior to this were cloud-hosted VMs that had a predefined stack (e.g. ASP.NET or J2EE or PHP or Cold Fusion, etc) to which we could upload our code and hope it all worked. There are always problems in managing configuration files of hosted apps and your hosted app NEVER behaves the same way while hosted as it does on your home PC. With Windows Azure, they're saying - quit worrying about the physical logistics - build your app, write your logic, use (cloud) data, and fahgeddaboudit. If the price is comparable - where are you going to host your back-end services? Amazon's EC2 or Azure, especially if you want to write your back-end services in .NET? 

If the prices are comparable, are you going to write your cloud app to use S3 data or SQL Services or Azure cloud storage?

Even just a few years ago, people didn't live on their computers - they thought of them the same way they thought of their graphing calculators - only they were more powerful. Now, people live on their computers. Moreover, they live online. They live connected. They live attached to the cloud. The problem is that right now, developers don't live attached to the cloud. 

Before cloud services, picture a meeting between a couple hobbyists who are thinking of building an app. They say, "Ok, we're going to need a web app.. but, we'll need some services and some central storage." At that point, they're forced to lease space in a data center, paying up front before anyone is even using their app, or they're forced to make COMPROMISES in their app's DESIGN to accomodate limitations of hosting companies.

With cloud services like Azure, those same people in that room talking about big ideas for big apps can now simply concern themselves with what they want their app to do instead of how they're going to manage the logistics.

-- That said, this is all on probably a 1.5 to 2 year time frame before this stuff is fully baked and they've got critical mass adoption. There is a lot of promise in Azure. Here's to hoping they pull it off.

tags: azure  windows  microsoft  cloud  cloudservices
links: digg this  del.icio.us  technorati  reddit