The last few weeks I’ve been exploring Windows Azure, Microsoft’s cloud computing platform.
This turned itself into a learning experience on several levels:
1. I haven’t done Windows software development in years
2. Getting to grips with MS’s development model vis-a-vis Java and iOS/Objective-C
3. Contrasting Azure against my experiences with Amazon Web Services and Google App Engine (GAE)
On the Windows side there doesn’t seem to be that same rich diversity and choice. I use the verb ‘seem’ on purpose: I may well be wrong and discover that as I spend more time with this platform. But for now it seems that Windows developers are missing out on the cross-pollination and opportunities to learn from each other that I see in the Java environment and even in the equally closed (as compared to Windows) iOS development environment. Maybe that is good blog entry of its own?
But back to Windows Azure itself and my experiences so far.
Most tutorials, books, blogs and sample code I found approach Azure from the perspective of a web site: serving up web pages, storing and retrieving the information that comes along with it. And many assume Windows (a PC, a phone, a server) on both sides of the virtual wire.
Regarding the latter, it is a function of the internet that you don’t know (or should not know/assume) the particulars of what is connecting to you. One entertaining result of this Windows-centric view is that while much of Azure is exposed as REST services, most of the sample code just make .NET method calls. Thus obfuscating the benefits of the platform-agnostic API that Azure does expose.
Regarding the former, that – a web site – is not the context I am looking into Azure for: instead of web pages served up, it is services that need to be served up to which different kinds of mobile devices will be connecting.
Azure distinguishes between web roles and worker roles. A useful simplification is to see a web role (or the collection of web roles in your project) as the web server and the worker roles as the background processes performing the computation, data mining and so on. This distinction is still something I’m getting to grips with: it seems you can do in a worker role what you can do in a web role and vice versa. So what really does this architecture give you?
This brings up a broader point. Design patterns, or best practices. In my project I wanted the mobile devices to communicate with my Azure project through a REST API. I know how to do this in Objective-C, and in Java. But how do you expose a REST API in C#/.NET and how do you receive GET, POST, PUT messages Azure-side? Much reading on MSDN, StackOverlow.com, other developers’ blogs showed that there are many ways to do this: as a WCF service, or use ASP.NET, or ASP.NET MVC, or…
Similarly to the question of where to keep the project’s data, there are many answers: local storage, Azure table or blob services, Azure SQL, or…
I admit that for sure in the first two weeks I had a hard time separating the trees from the forest. Now, a month or so further into the journey I have a much better feel for Azure’s application model but it was not easy arriving there from outside the Windows world.
There are two areas though where I really like to see improvements: deployment and diagnostics.
Currently my project consists of a fairly simple worker role that exposes several entry points via a REST API and maintains two tables. Still, a build & deploy from Visual Studio takes 10 minutes. That’s just an eternity in a develop-build-deploy-test cycle. In comparison, from Eclipse I build and deploy a much larger GWT+GAE project in just a minute or so. I am curious what the deployment time will be once the effort grows to the projected several worker roles, Azure AppFabric bus, certificate store and more.
Sometimes after some development my worker role won’t instantiate and Visual Studio ends up in an endless cycle of creating, starting, stopping, creating, starting, stopping cycle. Yes, I can retrieve information about why it is unsuccessful via diagnostics but I had really expected Visual Studio to be able to just get that for me: it knows the worker role failed to deploy so it should really also be able to get me the failure.
To get trace and other diagnostic information from my Azure project involves sprinkling trace calls throughout my code, configuring and setting up the diagnostics framework, transferring the collected analytic data to storage, and then retrieving that data. In my experience so far this is an error prone process where I sometimes seem to spend as much time trying to have the right data collected and then accessing it as I spend fixing the particular bug I’m trying to use diagnostics for. Together with the aforementioned deployment situation this makes for a slow and rather tedious development/testing experience. I miss the end-to-end debugging I can do with GWT+GAE and I miss the GAE dashboard where I can see in one glance the main issues for my app, its resource usage and its data store.
So far I like that Azure makes much use of standard web methodology – REST most notably – and that existing .NET applications should migrate quite easily to Azure thus gaining cloudiness. But that last point I see also as a weakness: little reason for non-Windows deployments to migrate to Azure, GAY and AWS will feel much more natural.
I’d love to hear your experiences with Azure. I’ll follow up with future entries as the project progresses. Possibly the next installment quite soon as later this week I’m attending the Azure bootcamp in Cambridge, MA!