When Microsoft first announced its Azure cloud computing platform, I wasn’t sure what to make of it. Was Microsoft just trying to jump on a buzzword bandwagon, or is the cloud computing paradigm really enterprise ready?

Once Azure was released in a ready-to-use form, I read some information about it, but very little of it was aimed at someone like me who did not know the fundamentals. and unfortunately, Microsoft has formed a really bad habit of putting useful information into online videos… as if anyone who works for a living has time to sit through three or four hour-long videos without even being sure if the video really contains the information that they need.

All the same, I was able to wade through enough of the available information to find out what Windows Azure is and the basic concepts behind developing for it.

Azure is a platform The first thing to understand is that Azure is not a product name per se, but rather it encompasses a variety of services that form a platform. The services that have been announced so far include the following:

• Windows Azure is a service that allows you to deploy code on Microsoft’s servers. This code has access to local storage resources (blobs, queues, and tables).
• SQL Azure is a cloud-located database offering. while it uses T-SQL like SQL Server, it is not a full SQL Server instance (for example, not all of the SQL Server built-in stored procedures are available). It can integrate with SQL Server, though.
• Azure AppFabric is a service bus that allows applications within your LAN to communicate with Azure clouds; it handles things like authentication, security, etc.
• “Dallas” is a marketplace for applications and services deployed on Windows Azure.

Windows Azure and SQL Azure are billed on a metered, usage basis, and Azure AppFabric is billed per connection. All three have additional charges for data transfer (full billing information here).

Also, there is an SLA, but to be blunt, the SLA is unacceptable for mission-critical applications (99.9 percent uptime guarantee). yes, “five nines” is expensive, but the promised “three nines” comes out to about 40 minutes of downtime a month. Can your business afford for the application to be down for that period of time? If not, you may very well want to pass on the Azure platform.

Windows Azure Writing code for Windows Azure uses the .NET environment; however, the code runs in Full Trust, so you can work with unmanaged code if needed. Instead of writing an application, you put your code in a Web Role or a Worker Role.

• A Web Role provides a single HTTP and HTTPS endpoint to your code, and it is very similar to an ASP.NET application. like working in ASP.NET, you can hook into global event handlers.
• A Worker Role is a piece of code that can run in the background, and can expose a wide variety of networking endpoints as needed, much like a WCF Service can. your code communicates with the Windows Azure system using either .NET libraries or a REST interface. This allows you to run non-.NET code on Windows Azure, as well as access resources on Windows Azure from non-.NET applications. When you deploy your code, you need to package it up and upload it to Windows Azure. You can also deploy it internally for testing purposes.

SQL Azure With SQL Azure, you can put your database in the cloud. This will require careful architectural considerations on your part; an application that is very “chatty” with the database will suffer greatly with the latency imposed (unless the application is also running on Azure). You can communicate with SQL Azure through an ODBC connection or ADO.NET, and there is a connector for PHP as well. You can work with your existing tools to connect to SQL Azure, and the expected capabilities like stored procedures, views, transactions, and so on are available.

Azure AppFabric Azure AppFabric acts as a gateway and a router between items on the Azure platform and items within your LAN, while also dealing with things like Active Directory federation, authentication, certificates and so on. Azure AppFabric can expose HTTP and REST endpoints, so non-.NET applications can work with it as needed. It can also allow anonymous users to access the applications it protects. It supports a variety of networking architectures including unicast and multicast one-way communications, and full-duplex bi-directional connections.

AppFabric feels more like a wrapper that requires a bit of configuration than a service where you will need to significantly rewrite code to work with.

“Dallas” “Dallas” is currently a CTP and is subject to change. It is a marketplace to buy and sell access to services running on the Windows Azure platform. You can provide .NET proxy classes to the customers, so they don’t have to deal with XML. in some regards, that feels like a step backwards. I think the idea is solid, but in all honestly, similar service marketplaces have not done well in the past (remember UDDI?).

Summary The Azure platform looks like an interesting choice if you’re a .NET developer, although I don’t know how the pricing stacks up compared to other services. I think that Azure would definitely be a good choice for things like batch processing (say, running reports, unit tests, integration tests, etc.) where it can be put under a heavy load and scaled down, and the SLA concerns are not a major issue.

Before considering Azure, you’ll definitely need to ensure that your application’s architecture works well with the cloud model and that means things like security, latency, network “chattiness”, and more. and anything mission critical that must function even if external connectivity is down is a no-go. It looks like moving to SQL Azure does not require a tricky migration or code rewrite, while putting existing code onto Azure will require some amount of effort to do so.

For more on this topic, read the TechRepublic column 10 reasons to use Azure for your cloud apps.

Justin James is an employee of Levit & James, inc. in a multidisciplinary role that combines programming, network management and systems administration. He has been blogging at TechRepublic since 2005.

• 0 Comments