Thanks for expanding on your earlier comments - it certainly seems daunting when you look at the entire product line, perhaps this would be a good topic for a future interview. I wonder how many other niners are confused by the branding/naming of Azure?
Thanks for your feedback on the naming. Let me try and a clear a few things up and not put my foot in my mouth.
Windows Azure Platform - is the cloud offering that allows developers to build applications and services in the cloud. It features Windows Azure, SQL Azure & .Net Services. The word Azure is used as the secret cloud sauce! Azure in this sense provides all
the "magic" - hosted, deployment, monitoring, availabilty, scalability, automated operations etc. So the Azure word on the end of SQL and Windows signifies the cloud versions.
The exception here is .Net Services - which whilst runs in the cloud, doesn't need any other cloud peices (you could use the service bus to go customer-customer without a cloud) and .Net Services doesn't have a non-cloud version to differentiate from.
Live is more geared to user centric and social applications, and could be consumed by cloud/hosted/onpremises services.
As we get feedback from customers and new features come on line, I'm sure there will be more "tweeks" of the naming.
On the subject of Tables being a Joke. It really depends upon why you need to use them.
If your data has complex relationships, you need to aggregate data, query based upon multiple parameters, then Windows Azure Tables may not be the right answer. For this kind of "storage", you really need compute + storage. There are 2 choices for this.
1. Use SQL Azure - SQL Azure is essentially SQL Server hosted in the cloud, with all the infrastructure/operations elements taken care of. You only need worry about the database. This will give you the SQL functionality you know and love. Remember SQL Server
is maintaining those indexes/views etc. that make querying the data easy.
2. Use Windows Azure Storage to store the data and Windows Azure compute to maintain de-normalized data. Here you do have to do some work yourself.
If you data can be found by using a key and is usually accessed as such, or you have semi-structured data - then Windows Azure table storage could be a good answer. When thinking of tables, think of them more as collections of entities. Each entity in the
table could be a different structure. Entities are organized by partition key. Entities with the same partition key are together on disk. Partitions can be on the same storage server as each other, or on different servers. This allows us to scale out, but
also we can potentially move hot partitions onto other servers. On the scale out side, tables are designed for scale, so billions of entities across x partitions.
Using Entities, you could store a users profile, wish list, shopping cart, invoices and past orders all in the same partition, and read all that data in a single API call.
Hope this gives you some more ideas on tables, but chime in with your thoughts.
Thanks for the comments on this. I'll try to clarify a few things, or at least provide more information/fuel for the discussion.
Pricing per instance is indeed $86.40, and for SLA's to kick in you would need 2 instances ($172.80) more on SLA's below.
So now there are some applications/services that probably don't make a lot of sense. As an example, I probably wouldn't want to run my blog at $172.80+ /per month, but if I am an ISV, I may want to host my multi-tenant CRM application in the cloud.
Part of the value of the cloud, is the ability to scale up and down and only pay for what I consume. Let's say I'm in the travel business, and Jan/Feb are the 2 busiest months of the year, where I need 100s of servers to handle the load. The rest of the
year I could be running 10s of servers to handle the load. If I run this in my own datacenter, I need 100s of servers. If I host this in Windows Azure, then I only pay for those servers/instances I use. So in Jan/Feb I'll be paying for 100s of servers/instances,
and the rest of the year only 10s. The great thing is, if there is a unforseen spike, I can simply add more servers/instances. I can also remove servers/instances when times are quiet.
The other thing to keep in mind is that we do all of the infrastructure work for you. We manage and maintain the OS, network, load balancers, DNS, cooling, monitoring, availability, disaster recovery, hardware maintenance etc. All you really need to worry
about is building your application. The simple example is that if there is a hardware failure, we simply move you to another server. No need for you to get involved there. Couple that with the ability to scale up and down and I think its pretty awesome.
On the point of SLAs - we hint at some SLA's on the pricing page at
http://www.microsoft.com/azure/pricing.mspx, but don't go into specifics. At commercial availability there will be detailed SLA information as well as details of retrobution/consequences etc. The final billing/SLA model will also help clarify the question
around DOS attacks etc.
Google App Engine have a different approach to Windows Azure, where we allow you to control absolutely the number of instances running, Google App Engine do not. There are pros and cons to both approach depending upon the application/service you want to