What up with not covering the azure outage??? I've been waiting for you guys to go through that. Not even mentioning it seems cowardly and like you're trying to keep it quiet. C'mon! You're better than this!
Also: What happened to fullscreen video? Can't find out how to do it now that the silverlight player is gone.
Thanks for your answer and your excellent blog post! I'm currently working with a relatively small dataset (only 80 GB database on-premise) and sharding up to hundreds of nodes is a whole other story. In this space SQL Azure Federations is truly a lifesaver!
But SQL Azure Federations could become the cloud database-solution numero uno or the de facto standard! If it just works out-of-the-box for small federations upto like 10 shards. I would guess that 90% of real-world databases would fit in this category, or maybe even with fewer shards?
I want true elasticity - scale out and scale in - without downtime. As of now, it's only possible to scale-out without downtime. If you want to reduce the number of shards you need to take the production system offline.
I want to be able to write simple sql commands like DELETE Customers WHERE CustomerID IN (X, Y, Z) without having to worry if X, Y, Z is in the same shard or not. Why not just distribute out the sql command to all shards and join them together before my SqlCommand gets the results back? I see that this might hurt performance, but not necessarily! It's faster to let 3 servers process this command in parallell than to have it execute in only one server if your dataset is huge. In the very least let there be an option to do it, and let developers have the option to choose simplicity vs. performance.
"Connection string vs. USE FEDERATION statements"
What I meant here is simply that the difference between having 3 SQL Azure databases and 3 different connections strings in your production-code to reach them is essentially the same as having a SQL Azure Federation with 3 shards and starting every SQL command with "USE FEDERATION ..." statements to reach the correct database shard. From a practical standpoint SQL Azure Federations doesn't add that much practical added value to the cost, implementation or maintenance of production systems, as I see it.
SQL Azure Federations could be great. What's the deal with having to specify which shard to access using the USE FEDERATION statement?
As I see it, it doesn't make much of a difference in having to incorporate these statements in every sql-statement and actually having n number of different connection-strings in your code. The only real functionality given here is that it's easy to scale out your database to many shards, and that's it. Going from SQL Aure to SQL Azure Federations still requires you to significantly change your code.
Honestly, I think that the SQL Azure Federation story today is weak. There needs to be a higher abstraction level so that you don't need to handle the different shards in your code. Isn't this obvious?
Dude, don't mix bribery and progressive tax legislations! We have progressive taxes in Norway where I'm from and that's working out just fine! Sure I have to pay 50% tax and also 25% VAT on everything I buy... But don't come here on Channel9 which is an international developer site and come dragging along your USA-centered politicial views like everyone in the world shares dem, m'kay?
@smarx: What I mean with "Internet connection redundancy" is: How is connectivity out to the world done in Azure? My cloud-webapp in xxxx.cloudapp.net points to an ip-address at the azure data center. What happens if your ISP goes down? Like the main cable is cut from the azure datacenter my app is hosted on or something like that. Did that clarify my question?
Good show! I have two questions I would like answered:
How is internet connection redundancy done in Azure? On my on-premise datacenter this is done by having two separate ISPs with different IP-ranges. The problem then is that it takes like 60 min to update the DNS entries if the primary ISP goes down and I need to emergency-switch to the secondary. See where I'm getting at?
The new "Azure connect" and what-not is a bit confusing, will Azure finally have static IPs? The reason I'm asking is that a lot of my connections require fixed IP-addresses over tcp/ip.