I'm not adverse to the google idea, but the NoSQL issue is a lot bigger than the NoSQL proponents make it. In simple terms, it make sense to keep objects together when they only make sense while part of a bigger construct. A Customer, for example could contain multiple orders which could contain multiple items. Saving this in some NoSQL flavor is convenient and easy to understand, but when your store is a branch and headquarters wants a report on how many widgets were sold that day, the report becomes a bit more complicated. And once you start managing things outside of the realm of the fictional widget store, you find that it isn't that easy to segregate objects like that.
So, you are effectively saying that Google's solution is super-duper-dee-awesome and it's FREE, but you'll need to rewrite your application so that it doesn't work with a relational database and you'll need to 'Write a web-page' whatever that means.
You are, at best, oversimplifying this comparison.
Like I said, if your app is already written in dotnet against SQL, go Azure
I am not advocating NoSQL, but it seems to me Google knows knows a thing or two about web-hosting. Being naive, I believe them .
RE 'write a web-page', I meant you DO NOT have to learn about instences, ramp-up or down, routing, balancing. For example, write a simple page to show retrieve a data-point from BigTable and you are done. Google takes care of scalability and promises that BigTable will scale. It's so simple and revolutionary, that MSFT must and will copy the idea.
By making fun of AppEngine only you stand to lose. I recommend watching Google developers videos on youtube. They also address the (what you called) vendor lock-in problem from the start.
Saving this in some NoSQL flavor is convenient and easy to understand, but when your store is a branch and headquarters wants a report on how many widgets were sold that day, the report becomes a bit more complicated.
I don't know much about Azure nor GAE, but I do know Azure has a NoSQL key/value store built in (Azure Table Storage) and has from the beginning.
Gu simply gets things done right. I expect big things from that department now. I hope SL continues after the changes and doesn't disolve into the HTML5+JS story.
I'm not saying it couldn't be done, just that it's more complicated. You have to logically implement what exists naturally when you use a relational database.
They both have uses and some of those uses overlap, but they are not easy replacements of each other.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.