We have very large SilverLight based applications. Where our applications are dealing with large amount of data. And we are planning to host our applications on Cloud. Our Main application is base for few other application. But due to some reason we always need a Cloud Drive with Drive Letter C. But Cloud Drive every time assign the arbitrary drive letters.
And we think this is very important requirement for those who are using Silverlight based project with Cloud Drive.
So Please Azure Cloud Drive team look at this request and process it as soon as possible and let all the developer know who want to use Cloud Drive with Silverlight.

As a developer, I feel that Azure is really locked down right now. It's really hard to do anything closer to the platform level, and if the core services doesn't have a feature, we're often out of luck until the Azure team gets around to implementing a solution.

I believe Azure would be much better off if it started to remove some of the restrictions on developers, so we can be creative and implement platform level solutions of our own, perhaps adding to the Azure ecosystem.

Personally, I'd really like to develop applications for Azure, and every 6 months or so, I come back and do an evaluation. But unforunately, I always end up going back and implementing the new application on AWS.

The basic reason is Azure introduces way too much friction for the poor developer bulding an application. There is a long list of reasons for this friction, including:

* The Windows VMs being so locked down.
* Inabliity to route TCP traffic (internal or external) to web roles.
* No support for UDP which means Azure can't host DNS or VoIP based applications.
* No support for multicast (internally) to so that we can implement our own discovery mechanisms to augment the limited (maybe non-existent) discovery provided by Azure.
* Allow external access to specific instances running on Azure and then let us RDP in. It's really hard right now to diagnose problems while developing applications that have problems on the production infrastructure that don't happen in the development environment.
* The combination of the excessively slow (7-8 minute) application deployment time and the inability to RDP into an instance really impacts developer productivity. A code-deploy-test cycle on Azure takes maybe 20 minutes per run (including getting a coffee while Azure deploys). On AWS, this is 1-2 minutes if I build on my remote machine and SCP changes files up to the AWS instance, or seconds if I have an instance with Visual Studio installed where I can just edit and hit F5 right on the server.
* Azure essentially requires a significant port for any non-toy application whereas most existing applications can be deployed to AWS with few or any changes.

Azure needs to be able to support other Microsoft technologies. It's crazy what I could deploy applications based on Microsoft .NET 4.0 RC Framework, Microsoft SharePoint, Full SQL Server, BizTalk server (or whatever it's called now), etc to Amazon Web Services today (or the past year), and yet none of these are supported on Azure. The best we seem to hear from the Azure team is that these are coming soon (e.g. .NET 4.0), or to submit a feature request to this forum.

The basic problem with Azure is that Microsoft has locked the platform down so much that only the Azure team can really inovate at the platform level. Most (maybe all) other on premise MSFT technologies won't work out of the box and you're locking us developers out of the equation as well. This leaves the Azure team as the choke point for advancing the platform. I believe that in the long run, this is really going to put a damper on Azure's success.

I love to work with Microsoft tools and technologies and I'd really love to develop applications on Azure. The problem for me right now is that Amazon Web Services does a far better job than Azure right now enable the Windows developer to deploy create applications.

Jeff Lill
jeff@lilltek.com

Application deployment ispainfully slow at 7-8 minutes. I imagine Azure must be booting a fresh VM for each node being deployed.

Why not keep unassigned VMs of various sizes available in inventory, waiting for a role instance assignment. Then, all Azure would have to do is deploy the application bits, do the network/appfabric magic to hook up the load balancer and then start the app. Should take seconds to deploy small applications.

After the role instance exits, Azure would wipe and reboot the instance and then put it back into inventory.

It seems to me that this could be a nice advantage over AWS, which has such a large number of AMI combinations that it would be really tough to manage such an inventory.

Azure on the other hand, will have a relatively small number of popular OS versions.

Cloud Drive is very helpful for those who are using standard NTFS APIs like us.

Actually we are working on application which will run both on cloud and on local machine. We need to store and use our large amount of data which will be used by our application to azure storage. and both local and cloud running application have to save and retrieve data from one location. Initially we are concentrated on blobs but looking at cloud drive we want to shift on to it.

In terms of Cloud Drive and our application running in cloud its awesome.
But But the application running in local environment have no access to cloud drive.

Cloud Drive functionality should be available Locally in future

Was wondering what others thought about "tiering" this more than a simple fixed storage transaction rate ? i.e. something more like

$0.01 - 10K up to 10 million
$0.008 - 10 million 15 million
$0.005 - 15 million+

Something like this ?

It just seems that transactions can be eaten up really quickly and there is no pricing mechanism to facilitate heavy users ?

Generally, the sessionState based problem - http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/1436b9fe-c899-46c8-813a-82b919273dda - is the worst and it just destroy transaction volumes. MSFT have acknowledged the problem - so this is the primarily reason.

I am sure there are many other people having issues with this and heavy users should really be discounted otherwise we could simply change CDN to Amazon based CDN and storage and reduce requests to table storage on Azure ?

But why do this when MSFT could simply make it more attractive?

Smart cards allow for a very high level of security. This is why Microsoft uses it for employees who need remote access to the Microsoft network. It’s difficult for an external computer to log onto the Microsoft network without a smart card. A user name and password is not enough.

A smart card would give some corporate customers confidence if they could give their employees a more secure way for logging onto their applications than standard credentials.

External consumers might want it too, to safeguard their identity. Such customers would have a choice of either the standard login or enhanced login.

Scenario:
A user logs on using their Windows Live credentials. They can then change their Windows Live preferences. They can set their preference to accept either standard login with user name and password, or enhanced security with user name, password and smart card.
Alternatively, a user could opt to log onto Microsoft Live with just their Smart Card.

For those using enhanced security, the user gets logged out when the smart card is removed from the reader. Since security related employee and customer information is never stored on the computer, the loss of a computer is not a danger. The loss of a security card is also not a danger since it can be revoked.

The Identity token generated would mention weather enhanced security was enabled. This is for corporate customers who require it. Such corporate customers who require enhanced security would be responsible for issuing cards and replacing lost or stolen cards.