Big Wish List for Windows Azure
At Lokad, we have been working with Windows Azure for more than 1 year now. Although Microsoft is a late entrant in the cloud computing arena, So far, I am extremely satisfied with this choice as Microsoft is definitively moving forward in the right direction.
Here is my Big Wish List for Windows Azure. It’s the features that would turn Azure into a killer product, deserving a lion-sized market share in the cloud computing marketplace.
My wishes are ordered by component:
- Windows Azure
- SQL Azure
- Table Storage
- Queue Storage
- Blob Storage
- Windows Azure Console
- New services
Windows Azure
Top priority:
- Faster CPU burst: The total time between initial VM request (through the Azure Console or the Management API), and the start of the client code execution is long, typically 20min, and in my (limited) experience above 1h for any larger number of VMs (say +10 VMs). Obviously, we are nowhere near real-time elastic scalability. In comparison, SQL Azure needs no more than a few seconds to instantiate a new DB. I would really like to see such an excellent behavior on the Windows Azure side.
- Smaller VMs: for now, the smallest VMs are 2GB large and costs $90/month, which brings the cost of a modest web app to 200 USD/month (considering a web role and a worker role). Competitors (such as Rackspace) are already offering much smaller VMs, down to 256MB per instance priced about 10x cheaper. I would really like to see that on Azure as well. Otherwise, scaled down apps are just not possible.
- Per minute charge: for now Azure is charging by the hour, which means that any hour that your start consuming will be charged fully. Obviously, it would be a great incentive to improve performance to start charging by the minute, so that developers could really fine tune their cloud usage to meat the demand without wasting resources. Obviously, such a feature makes little sense if your VMs take 1h to get started.
- Per-VM termination control: Currently, it is not possible to tell the Azure Fabric which VM should be terminated; which is rather annoying. For example, long running computations can be interrupted at any moment (they will have to be performed again) while idle VMs might be kept alive.
- Bandwidth and storage quota: most apps are never supposed to be require truckloads of bandwidth or storage. If they do, it just means that something is going really wrong. Think of a loop endlessly pooling some data from a remote data source. With pay-as-go, a single VM can easily generates 10x its own monthly costs through a faulty behavior. To prevent such situations, it would be much nicer to assign quota for roles.
Nice to have:
- Instance count management through RoleEnvironment: The .NET class
RoleEnvironmentprovides a basic access to the properties of the current Azure instance. It would be really nice to provide here a native .NET access to instance termination (as outlined here above), and instance allocation requests - considering that each role should be handling its own scalability. - Geo-relocation of services: Currently, the geolocation of a service is set at setup-time, and cannot be changed afterward. Yet, the default location is “Asia” (that’s the first item of the list), which makes the process quite error-prone (any manual process should be considered as error-prone anyway). It would nicer if it was possible to relocate a service - eventually with a limited downtime, as it’s only a corrective measure, not a production imperative.
SQL Azure
Top priority:
- DB snapshot & restore toward the Blob Storage: even if the cloud is perfectly reliable, cloud app developers are not. The data of a cloud app (like any other app btw) can be corrupted by a faulty app behavior. Hence, frequent snapshots should be taken to make sure that data could be restored after a critical failure. The ideal solution for SQL Azure would be to dump DB instances directly into the Blob Storage. Since DB instances are kept small (10GB max), SQL Azure would be really nicely suited for this sort of behavior.
- Smaller VM (starting at 100MB for $1 / month): 100MB is already a lot of data. SQL Azure is a very powerful tool to support scaled-down approaches, eventually isolating the data of every single customer (in case of a multi-tenant app) into an isolated DB. At 10/month,theoverheadistypicallytoolargetogoforasuchastrongisolation;butat10/month,theoverheadistypicallytoolargetogoforasuchastrongisolation;butat10/month, the overhead is typically too large to go for a such a strong isolation; but at 1/month, it would become the de-facto pattern; leading to smaller and more maintainable DB instances (as opposed to desperately trying to scale up monolithic SQL instances).
- Size auto-migration: Currently, a 1GB DB cannot be upgraded as 10GB instances. The data has to be manually copied first, and the original DB deleted later on (and vice-versa, the other way around). It would be much nicer if SQL Azure was taking care of auto-scaling up or down the size of the DB instances (within the 10GB limit obviously).
Nice to have:
- Geo-relocation of service: Same like above. Downtime is OK too, just a corrective measure.
Table Storage
Top priority:
- REST level .NET client library: at present time, Table Storage can only be accessed though an ADO.NET implementation that proves to be rather troublesome. ADO.NET feels in the way if you really want to get the most of Table Storage. Instead, it would be much nicer if a .NET wrapper around the REST API was provided as low-level access.
Nice to have:
- Secondary indexes: this one has already been announced; but I am re-posting it here as it would be a really nice feature nonetheless. In particular, this would be very handy to reduce the number of I/O operations in many situations.
Queue Storage
Nice to have:
- Push multiple messages at once: the Queue offers the possibility to dequeue multiple messages at once; but messages can only be queued one by one. Symmetrizing the queue behavior by offering batch writes too would be really nice.
Blob Storage
Nice to have:
- Reverse Blob enumeration: prefixed Blob enumeration is probably one of the most powerful of the Blob Storage. Yet, items can only be enumerated in increasing order against their respective blob names. Yet, in many situation the “canonical” order is exactly the opposite of what you want (ex: retrieve blob names prefixed by dates, starting by the most recent ones). It would be really nice if it was to possible to enumerate the other way around too.
Windows Azure Console
The Windows Azure Console is probably the weakest component of Windows Azure. In many ways, it’s a real shame to see such a good piece of technology so much dragged down by the abysmal usability of its administrative web client.
Top priority:
- 100x speed-up: when I say 100x, I really mean it; and even with 100x factor, it will still be rather slow by most web standards, as refresh latency of 20min is not uncommon after updating the configuration of a role.
- Basic multi-user admin features: for now, the console is a mono-user app which is quite a pain in any enterprise environment (what happens when Joe, the sysadmin, goes in vacations?). It would much nicer if several Live ID could be granted access rights to an Azure project.
- Billing is a mess, really: beside the fact that about 10 counter-intuitive clicks are required to navigate from the console toward your consumption records; the consumption reporting is still of substandard quality. Billing cries for massive look & feel improvements.
Nice to have:
- Project rename: once named, projects cannot be renamed. This situation is rather annoying as there are many situations that would call for a naming correction. At present time, if you are not satisfied with your project name, you’ve got no choice but to reopen an Azure account; and starts all over again.
- Better handling of large projects: the design of the console is OK if you happen to have a few services to manage, but beyond 10 services, the design starts being messy. Clearly, the console has not been designed to handle dozens of services. It would be way nicer to have a compact tabular display to deal with the service list.
- Aggregated dashboard: Azure services are spread among many panels. With the introduction of new services (Dallas, …), getting a big picture of your cloud resources is getting more and more complex. Hence, it would be really nice to have a dashboard aggregating all resources being used by your services.
- OpenID access: Live ID is nice, but OpenID is nice too. OpenID is taking momentum, I would be really nice to see Microsoft supporting OpenID here. Note that there is no issue to support LiveID and OpenID side by side.
New services
Finally, there are a couple of new services that I would be thrilled to see featured by Windows Azure:
- .NET Role Profiler: in a cloud environment, optimizing has a very tangible ROI, as each performance gain will be reflected through a lower consumption bill. Hence, a .NET profiler would be a killing service for cloud apps based on .NET. Even better, low overhead sampling profilers could be used to collect data even for systems in production.
- Map Reduce: already featured by Amazon WS, it’s such a massively useful for the rest of us (like Lokad) who perform intensive computations on the cloud. Microsoft has already been moving forward with DryadLinq in this direction, but I am eager to see how Azure will be impacted.
This is a rather long list already. Did I forget anything? Just let me know.
Reader Comments (7)
Thanks for taking the time to share your ideas with us Joannes, really appreciate you taking the time to do this. Based upon the mails I saw earlier today I know a few folks on the team already read your post, but this afternoon I will be sure to share your wish list with other relevant members of the Windows/SQL Azure Team. Keep the ideas coming and thanks again, Mike | Mike Wickstrand | Senior Director, Product Planning | | Windows Azure | Microsoft | | Email: mikewic@microsoft.com | Twitter: @Wickstrand | | Blog: blogs.msdn.com/wickstrand/ |
February 8, 2010 | Mike Wickstrand
Joannes I completely agree with you on the billing front, its abysmal and doesn’t really tell you anything useful, especially if your app is multi tenanted. It would be far better for (e.g.) the storage billing to at least show you the container that was accessed so that you have a bit better granularity. Even better would be to show you the URL that was used then we might actually end up with something that is useful. The response on this poor billing has always been “Oh then run up some extra web/worker roles to act as counters” and there are 2 reasons why this is bad. First as all data is now coming through your web/worker role your code is now the weakest part of the download system (rather than hitting the massively scaleable blob storage directly), and secondly it costs $$$ to run up extra roles to handle the fact that the billing is weak. Howard.
February 9, 2010 | Howard Smith
Excellent wish list Joannes. Hope MS folks are listening.
February 9, 2010 | Sarang
@ Joannes: Great feedback. @ Mike: Good response. Nice to see the team being responsive to user suggestions.
February 9, 2010 | Paul
Support for ASP.NET sessions in SQL Azure would be great - the custom ASP.NET session provider that works with Azure Storage is slow and buggy. I’m lobbying for this feature, so please vote here:
www.mygreatwindowsazureidea.com/forums/34685-sql-azure-feature-voting/suggestions/472024-add-support-for-asp-net-sessions-in-sql-azurePlease add support for ASP.NET sessions in SQL Azure. Although the membership and roles providers currently work with SQL Azure, the session provider does not. If we have more than 1 instance of our web roles we are forced to use the custom ASP.NET session provider that uses Azure Storage which is very slow and buggy. I have a whole thread on this in the forums:social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/b87cadf1-2918-43d3-972f-0fb32f13d5caFebruary 10, 2010 | Emmanuel Huna
@Emmanuel ASP.NET sessions are indeed important. In my wish list, I have tried to focus on the Azure services themselves, as opposed to client libraries. It is very much possible for the community to fix a broken session provider, but faster CPU bust (for example) is beyond the reach of the community: the fix has to come from Microsoft. Then, the real question behind the ASP.NET Session issue is the fact that Azure does not provide “Caching as a Service”. I will try to post more about it.
February 15, 2010 | Joannes Vermorel
You really have lots of great ideas. I agree that there are still lots of improvements and tweeking needed to be done in Azure. Keep those ideas coming and I’m sure these will help the developers improve the product. Duncan Samuel Online Invoicing
June 11, 2010 | Duncan Samuel