Why MS Azure sucks a bit less today...
-
So you're saying avoid SQL Azure? It's not worth the effort and cost?
I am saying if it can be avoided, avoid it. Rather, if your data can be modeled using "Azure tables" and "Azure blobs" prefer them over the SQL Azure.
-
I am saying if it can be avoided, avoid it. Rather, if your data can be modeled using "Azure tables" and "Azure blobs" prefer them over the SQL Azure.
I cannot see a situation where I could convince a client that a "Flat file in the clouds" is a better model than a Relational SQL Model. I would get laughed out of their office! :omg: There is very good reason why both Amazon and M$ Azure are offering Relational models - clients demand them! Please write an article. I think you make some compelling points and I for one would like see them layed out in an CP article. Thanks Rama.
-
I cannot see a situation where I could convince a client that a "Flat file in the clouds" is a better model than a Relational SQL Model. I would get laughed out of their office! :omg: There is very good reason why both Amazon and M$ Azure are offering Relational models - clients demand them! Please write an article. I think you make some compelling points and I for one would like see them layed out in an CP article. Thanks Rama.
Don Burton wrote:
Flat file in the clouds
Nobody said anything about flat files. Azure has concept of tables and blobs. The Azure tables are not relational in the same way as a SQL database but it supports a concept of partition key and a row key. The partition key is a hint to Azure indicating that the data in a particular partition can be stored to a different storage server. By carefully partitioning your data you can make your applications scalable. For instance, if you are developing a application that can be used by a car dealership and you have data from several car dealers. You can partition your data in such a way that each dealer gets his own partition key may be his own server (based on some Azure's algorithm). This, ensures scalability of the application. SQL Azure has no such concept and so you may have to do lot of manual work to distribute the data across servers.
Don Burton wrote:
clients demand them!
I never said clients do not demand them.
-
Don Burton wrote:
Flat file in the clouds
Nobody said anything about flat files. Azure has concept of tables and blobs. The Azure tables are not relational in the same way as a SQL database but it supports a concept of partition key and a row key. The partition key is a hint to Azure indicating that the data in a particular partition can be stored to a different storage server. By carefully partitioning your data you can make your applications scalable. For instance, if you are developing a application that can be used by a car dealership and you have data from several car dealers. You can partition your data in such a way that each dealer gets his own partition key may be his own server (based on some Azure's algorithm). This, ensures scalability of the application. SQL Azure has no such concept and so you may have to do lot of manual work to distribute the data across servers.
Don Burton wrote:
clients demand them!
I never said clients do not demand them.
You can call anything you want - compared to the relatonal model they are FLAT FILES (or linked lists). Nobody I know would write a data application (and want to get paid) that follows the model you're recommending. How many client production installs do have in place based on your Azure model?
-
You can call anything you want - compared to the relatonal model they are FLAT FILES (or linked lists). Nobody I know would write a data application (and want to get paid) that follows the model you're recommending. How many client production installs do have in place based on your Azure model?
I already gave you reasons why Azure Tables are better than SQL Azure.
Don Burton wrote:
). Nobody I know would write a data application (and want to get paid) that follows the model you're recommending
How about Google: http://en.wikipedia.org/wiki/BigTable[^] and GFS[^]. It follows the same model of Azure Tables.
-
I already gave you reasons why Azure Tables are better than SQL Azure.
Don Burton wrote:
). Nobody I know would write a data application (and want to get paid) that follows the model you're recommending
How about Google: http://en.wikipedia.org/wiki/BigTable[^] and GFS[^]. It follows the same model of Azure Tables.
I say you're completely wrong in your analysis. If you're so convinced that Azure Tables are better than SQL Azure (and the inherent pricing) - write an article and let's see what the rest of CP thinks. I may be wrong about your logic. Let’s see.
-
I say you're completely wrong in your analysis. If you're so convinced that Azure Tables are better than SQL Azure (and the inherent pricing) - write an article and let's see what the rest of CP thinks. I may be wrong about your logic. Let’s see.
Such article already exists albeit by somebody else: Azure FAQ Part 1[^] Scroll down to "Why was not SQL preferred?". At this point, I am not sure whether you are trying to troll or trying to learn.
-
Such article already exists albeit by somebody else: Azure FAQ Part 1[^] Scroll down to "Why was not SQL preferred?". At this point, I am not sure whether you are trying to troll or trying to learn.
And you're trying to convince me that M$ prefers the non-SQL Azure model so that everyone will use non .NET languages? "Why was not SQL preferred? REST relies completely on HTTP protocols which enables other languages like PHP.JAVA to communicate with Azure storages. In other words you can build your application using any language like CGI, PHP and have your data stored in Azure storage." As for the "Troll" comment - you're the one who resurrected a 2 day old thread so nobody would see your failed logic. Write an article that convinces all of CP of your Azure logic. Isn't that a fair resolve to our argument?
-
And you're trying to convince me that M$ prefers the non-SQL Azure model so that everyone will use non .NET languages? "Why was not SQL preferred? REST relies completely on HTTP protocols which enables other languages like PHP.JAVA to communicate with Azure storages. In other words you can build your application using any language like CGI, PHP and have your data stored in Azure storage." As for the "Troll" comment - you're the one who resurrected a 2 day old thread so nobody would see your failed logic. Write an article that convinces all of CP of your Azure logic. Isn't that a fair resolve to our argument?
Don Burton wrote:
And you're trying to convince me that M$ prefers the non-SQL Azure model so that everyone will use non .NET languages?
Hmm...? You are mixing too many points here. Have you looked at any of the official Microsoft documents on the rationale behind Azure Tables and Blobs and Queues?
Don Burton wrote:
you're the one who resurrected a 2 day old thread so nobody would see your failed logic.
No on the contrary, I have other things to do. If you do not want to use or understand Azure, it's up to you. I personally get no benefit from that. For the benefit of others I am resurrecting this thread.
-
Don Burton wrote:
And you're trying to convince me that M$ prefers the non-SQL Azure model so that everyone will use non .NET languages?
Hmm...? You are mixing too many points here. Have you looked at any of the official Microsoft documents on the rationale behind Azure Tables and Blobs and Queues?
Don Burton wrote:
you're the one who resurrected a 2 day old thread so nobody would see your failed logic.
No on the contrary, I have other things to do. If you do not want to use or understand Azure, it's up to you. I personally get no benefit from that. For the benefit of others I am resurrecting this thread.
If you really wanted to "benefit" others - you would write an article that made your points and let everyone have opportunity to make theirs. Do you agree?
-
If you really wanted to "benefit" others - you would write an article that made your points and let everyone have opportunity to make theirs. Do you agree?
Yes, probably it does seem that lot of people have confusion about Azure. But my article will not make any new points, all the points are already available in Microsoft documents and blogs everywhere. Starting with :http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf[^] for general issues with Cloud computing the good and the bad. An article on BigTable which you call Flat files : http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/en/us/papers/bigtable-osdi06.pdf[^].
-
Yes, probably it does seem that lot of people have confusion about Azure. But my article will not make any new points, all the points are already available in Microsoft documents and blogs everywhere. Starting with :http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf[^] for general issues with Cloud computing the good and the bad. An article on BigTable which you call Flat files : http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/en/us/papers/bigtable-osdi06.pdf[^].
Rama Krishna Vavilala wrote:
But my article will not make any new points, all the points are already available in Microsoft documents and blogs everywhere.
I disagree! The M$ points are all propaganda. That's like saying I'll buy a car because the manufactuer says I should. You do make some good points. And while I do see "some" value in Azure (or Cloud Computing) I don't think the pricing is compelling enough to make a switch to the cloud from private computing.
-
Yes, probably it does seem that lot of people have confusion about Azure. But my article will not make any new points, all the points are already available in Microsoft documents and blogs everywhere. Starting with :http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf[^] for general issues with Cloud computing the good and the bad. An article on BigTable which you call Flat files : http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/en/us/papers/bigtable-osdi06.pdf[^].
This cleared up some of your points for me: Using Storage in the Windows Azure Platform http://live.visitmix.com/MIX10/Sessions/EX11[^]