Right now if I want a shared service (MongoDB for example) I need to either set up a dedicated MongoDB app and have my other applications talk to its load balancer or I need to create one Mega-App that has all my MongoDB services and MongoDB itself. Both of these approaches have pros and cons but are generally cumbersome.

The way Amazon does it is everything is assigned to a "security group". Security groups determine which ports are publicly accessible and everything in a security group can directly talk to every other machine in that security group through its internal IP. This makes setting up applications with shared infrastructure much easier.

With Smooth Streaming, because of the latency and low bandwidth during the first access of the video (before it is cached by CDN), Smooth Streaming will choose a low bitrate stream, and the higher bitrate streams may never be cached at the CDN edge server because they are never accessed; or if we are lucky it requires at least many replays of the video before all streams are cached. This is a huge problem with videos not frequently accessed.

Therefore it should be possible to force a container to cache all blobs within it as soon as one of its blobs is accessed.

This is relevant using the "Adaptive Streaming with Windows Azure Blobs Uploader" (http://blog.smarx.com/posts/smooth-streaming-with-windows-azure-blobs-and-cdn).

Currently while creating VNET we can specifiy the DNS server name which has to be already up and running with an IP.

To setup a complete private DNS on IaaS it is required to create vnet, then start adding VMs to it. At the point of creating the VNET, IP of DNS server is unknown as DNS server IP would be allotted with DHCP method (which is recommended by azure team) .

Right after creating VNET and join the DC VM to vnet, then only IP of DC would be known. At this point it is not possible to update VNET with DC machine. Atleast it is not possible to add more DCs to the VNET.

It is a huge benefit if this feature can be added for those who are automating labs or environments using API or powershell. Specifically for the scenarios like who wants to leverage IaaS for virtual labs, it is required to spin the labs with DC environment (multiple DC environments) on the fly and spin down when lab is done.

This is a huge benefit if this feature could be added.

Provide an out of the box story for indicating that role setting should be treated as a secret.

In doing so the expectation is that the value you manage in the settings UI needs to be encrypted when saved in ServiceConfiguration.cscfg, using a cert available on host where setting is added/modified, and decrypted when read back from ServiceConfiguration.cscfg in a deployment at runtime, where same cert is present in hosted service configuration.

Ultimately something similar to what gets done today automatically for the setting "Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword".

I realize blog posts exist outlining how you can do this yourself but having a single common out of the box solution for handling it keeps security reviews from having to inspect every team’s individual implementations to confirm no mistakes have been made.

There is no exposed meta-data around temporary tables within SQL Azure. Any logic that deals with objects dynamically is unable to learn anything about the current state (existence and definition) of temporary tables.
Here is one example…
If you need to execute multiple scripts within a single session (or execute a single script that is actually a concatenation of multiple other scripts), you can’t be sure the previous script removed any temporary tables it may have created. So before you create a temporary table you have to dynamically check for the existence of a temporary table with the same name and if found, then drop it. This is commonly performed on the on-premises version of SQL Server using logic like this…
IF EXISTS (SELECT 1 FROM tempdb.sys.tables WHERE object_id = OBJECT_ID('tempdb..#Example') AND type = 'U')
DROP TABLE #Example
GO

CREATE TABLE #Example (ID INT)
GO

However, this method relies upon a cross database query to examine the sys.tables within the tempdb to determine if the table exists. Because of the cross database nature of this query, this does not work within SQL Azure. There appears to be no way to handle this within SQL Azure. Maybe this can be solved be exposing information about temporary tables within the existing system catalogs or maybe a new system catalog?