3 features to make Azure developers say "wow"
Wheels that big aren’t technically required.The power of the “wow” effect seems frequently under-estimated by analytical minds. Nearly a decade ago, I remember a time when analysts where predicting that the adoption color screens on mobile phones would take a while to take off as color was serving no practical purposes.
Indeed, color screens arrived several years before the widespread bundling of cameras within cell phones. Then, at present day, there are still close to zero mobile phone features that actually require a color screen to work in smooth condition.
Yet, I also remember that the first reaction of practically every single person holding a phone with color screen for the first time was simply: wow, I wan’t one too; and within 18 months or so, the world had upgraded from grayscale screens to color screens, nearly without any practical use for color justifying the upgrade (at the time, mobile games were inexistent too).
Windows Azure is a tremendous public cloud, probably one of the finest product released by Microsoft, but frequently I feel Azure is underserved by a few items that trigger something close to an anti-wow effect in the mind of the developer discovering the platform. In those situations, I believe Windows Azure is failing at winning the heart of the developer, fostering adoption out of sheer enthusiam.
No instant VM kick-off
With Azure, you can compile your .NET cloud app as an Azure package - weighting only a few MB - and drap & drop the package as a live app on the cloud. Indeed, on Azure, you don’t deploy a bulky OS image, you deploy an app, which is about 100x smaller than a typical OS.
Yet, when booting your cloud app takes a minima 7 mins (according to my own unreliable measurements) to Windows Azure Fabric, even if your app require no more than a single VM to start with.
Here, I believe Windows Azure is missing a big opportunity to impress developers by bringing their app live within seconds. After all - assuming that a VM is ready on standby somewhere in the cloud - starting an average .NET app does not take more than a few seconds anyway.
Granted, there are no business case that absolutely require instant app kick-off, and yet, I am pretty sure that if Azure was capable of that, every single 101 Windows Azure session would start by demoing a cloud deployment. Currently, the 7 mins delay is simply killing any attempt at public demonstration of a Windows Azure deployement. Do you really want to keep your audience waiting for 7 mins? No way.
Worse, I typically avoid demoing Azure to fellow developers out of fear of looking stupid facing waiting for 7 mins until my “Hello World” app gets deployed…
Queues limited to 500 message / sec
One of the most enthusiastic aspect of the cloud is scalability: your app will not need a complete rewrite every time usage increases from a 10x factor. Granted, most apps ever written will never need to scale for the lack of market adoption. From a rational viewpoint, scalability is irrelevant for about 99% of the apps.
Yet, nearly every single developer putting an app in the cloud dreams of being the next Twitter, and thinks (or rather dreams) about the vast scalability challenges that lie ahead.
The Queue Storage offers a tremendous abstraction to scale out cloud apps, sharing the workload over an arbitrarily large amount of machines. Yet, when looking at the fine print, the hope of the developer is crushed when discovering that the supposedly vastly scalable cloud queues can only process 500 messages per second, which is about 1/10th of what MSMQ was offering out of the box on server in 1997!
Yes, queues can be partitioned to spread the worload. Yes, most apps will never reach 500 msg / sec. Yet, as far, I can observe looking at community questions raised by adopters of Lokad.Cloud and Lokad.CQRS (open source libraries targeting Windows Azure), queue throughput is a concern raised by nearly very single developer tackling Windows Azure. This limitation is killing enthusiam.
Again, Windows Azure is missing a cheap opportunity to impress the community. I would suggest to shoot for no less than 1 million messages / second. For the record, Sun was already achieving 3 millions message / sec one on a single quasi-regular server 1 year ago with insane latency constraints. So 1 million is clearly not beyond the reach of the cloud.
Instant cloud metrics visualization
One frequent worry about on-demand pricing is: what if my cloud consumption get out of control? In the Lokad experience, cloud computing consumption is very predictable and thus, a non-issue in practice. Nevertheless, the fear remains, and is probably dragging down adoption rates as well.
What does it take to transform this “circumstance” into marketing weapon? Not that much. It takes a cloud dashboard that reports live your cloud consumption, key metrics being:
- VM hours consumed for the last day / week / month.
- GB stored on average for the last day / week / month.
- GB transferred In and Out …
- …
As it stands, Windows Azure offers a bulky Silverlight console that takes about 20s to load on broadband network connection_._ Performance is a feature: _not having_ a lightweight dashboard page is a costly mistake. Just think of developers at BUILD discussing their respective Windows Azure consumption over their WP7 phones. With the current setup, it _cannot_ happen.
Those 3 features can be dismissed as anecdotal and irrational, and yet I believe that capturing (relatively) cheap “wow” effect would give a tremendous boost to the Windows Azure adoption rate.
Reader Comments (3)
Spot on features. I didn’t know about the 500 msg /sec limitation. The last point you made about real time stats is really a concern for me. I’m moving an application that I expect to grow into the cloud, and you can easily get concerned when the current reporting is that bad. I thought the latest improvements made were great. VM images etc., but I agree they have some work to do on the management features.
June 24, 2011 | Martin H. Normark
One specific sentence in your article got me thinking: Currently, the 7 mins delay is simply killing any attempt at public demonstration of a Windows Azure deployement How do Azure evangelists convince developers to use the platform? Do they go through a stack of slides without running a live demo? Do they only show the final result (which is missing one half of the “it’s simple and powerful” argument, namely the “simple” part)? .
June 26, 2011 | Victor Nicollet
Victor, I can’t tell for all evangelists, but there are two main tricks. 1) you launch your Azure deployment, then move on your slides and then gets back to your deployment 10min later. 2) you launch the deployment, then you tell the audience that you’re now switching to an identical app, but already deployed (fast forward).
June 27, 2011 | Joannes Vermorel