The very idea of clouds that could

I still find it amazing that people would consider micros~1 software suitable for serving on the public internet. I'll admit I haven't a clue about their latest; I do work with several open source operating systems on a daily basis and haven't touched redmondian software in at least half a decade.

Oh, and currently toying with a dull server for a client (running linux), and it's not all bad, in fact it has its share of pretty lights, though it clearly could be so much better if it wasn't a wintendo. Typing this on a dull laptop (again running linux); it works reasonably well enough but not entirely stable inside its cheap plastic case and sports a highly annoying touchpad that produces more false inputs than that it reacts to my direction the way I want it to. I want my trackpoint back.

But if micros~1 wants to go big in the cloud, well, let them. Like software as a service, it really isn't all that useful and has serious problems with privacy, ownership, guarantees of availability, what-have-you. It'll be the data thief's dream, which is an audience micros~1 has plenty of track record catering for. The idea of virtualising for the sake of virtualising and hoping you can shake out some residual side effect goodness is pretty bubbly thinking, if you ask me. But until we figure out this privacy thing for large scale computing it's likely to do more hidden harm than demonstratably good.

virtualization-friendly OS ?

Maybe Microsoft is also developping a virtualization-friendly OS for the Azure cloud? A previous article on El Reg raised the issue of OS bloat in a virtualized anvironment when you have to run 5 identical instances of the same OS in order to get 5 virtual servers out of one box. The article suggested that a virtualization-friendly OS would run just one instance of the OS and five thin sandboxes for the virtual servers. OS vendors have no incentive to develop such a thing because they prefer selling multiple OS licenses. But when the OS vendor itself has to pay for the servers, disks and memory, maybe an optimization by a factor of 2-3 sounds appealing all of a sudden.

Only One Question

Will it have an Azure Screen of Death, or just the plain Blue one ?

Azure Storage makes 3 copies of all data

In the Azure documentation, they claim to make 3 synchronous writes to different storage arrays for each write i/o. Presumably, that is in a software driver stack implementation, and i would guess that it's networked storage of some sort. That would allow very cheap storage, possibly without the need for true RAID or expensive 3rd party storage vendors.

Are you sure this is so different?

The nonsense that gets talk is amazing and, I think, demonstrates that the author has not coded against Azure or, at least, given any thought to how the basic storage service available on Azure might be implemented using off-the-shelf components. And what's this about workers and web being Hyper-V partitions?

Let's start with storage (table or blob). Azure storge is really primitive and could be implemened using standard (for Microsoft) NTFS and a single SQL Server table (well, two - one of 'tables' and one for blobs). Let's go with the blob case because its the simpler of the two cases. In the meantime imagine a single table row being a blob with some field data saved as an Xml file rather than an image or other binary object.

Imagine the single blob table indexed by:

your user account id;

an internally selected volume name (so stuff can be moved around);

the storgage path you designate;

a key (so a blob is unique within the path);

an internal, unique entity name;

a user friendly name; and

mime type

That's it, one table with 7 fields. There may really be more but they are not required and the table table will be slight different (no need for a mime-type).

This table is in SQL Server and is just indexing blobs. Even if there are many trillions of rows in the table, SQL server is going to handle it either because accounts are balanced across multiple SQL server instances or some other existing IIS/SQL server method. Importantly this table is itself a file stored on standard (if high end) hardware but stuff that can be bought from the usual suspects.

If the accountid + path doesn't exist on the selected disk volume its created and the content is written as a file. This is bread and butter for standard NTFS. The same NTFS which hosts untold exabytes all over the world.

The blob's file can be retrieved by IIS from disk after a simple database lookup based on your account id and the requested path/blob.name (IIS has standard function to do this) so, again, all standard stuff. Pretty much what I guess Amazon Web Services does on their SimpleDB (but using some other DB tech and Linux).

A table with 7 fields and normal NTFS is hardly a recipe for a new storage OS any more than Chrome is a recipe new OS. Using NTFS as the means to handle storage of arbitrarily large content (which its pretty good at) also means Microsoft can turn to the normal vendors of storage products and buy their standard product. No need for proprietary anything - except Windows, NTFS, IIS and SQL Server - and certainly no need for new stuff.