And How is it different from just making an SQL Server accessible from the internet?
tx & regards Lothar
And How is it different from just making an SQL Server accessible from the internet?
tx & regards Lothar
It's not really all that different from making a SQL Server accessible from the Internet - except with SQL Azure, you don't have to deal with routing, making sure power is available even during a thunderstorm, keeping the server up and running, applying the latest security patches, dealing with internet connectivity, adding RAM as needed, swapping out defective harddisks as needed, load balancing amongst a farm of 20 servers and so on and so forth - the Microsoft DataCenter will do all that for you.
Plus the DataCenter should scale really well - if you happen to have a brilliant idea and suddenly you need 20 servers instead of just one - the MS DataCenter will happily provide that for you.
So it's really a bit like outsourcing a very flexible, scalable data center including staff to a third party (here: Microsoft).
Marc
The whole concept of cloud services is to abstract away the gory details of hosting applications and services over the internet. If you've ever run your own web server you can appreciate the pain and suffering this avoids.
In order for a cloud to be useful for your typical application, it must provide services for storing files, hosting websites, and data services at a minimum. Sql Azure provides the data services for Azure.
Why not just a sql server? Well, you can always host your own database on some server somewhere and consume it from a website hosted on Azure... but what happens when your website becomes popular? Your Sql Server now isn't serving data fast enough, so you have to move all your stuff to a bigger server, buy more bandwidth, etc. And then when you get more popular, you go through the same thing again.
All you have to do is read the posts on the StackOverflow blog about Jeff dealing with the hardware and software trials of handling the load this site is generating.
Its called a pain in the ass.
With Sql Azure, as your website grows the bandwidth and storage for your data increases dynamically. If you serve a gig a month or a hundred, you pay for what you use and you don't have to worry about upgrading your servers. That's the power of cloud computing.
Are you asking what is the difference from your point of view as an consumer of the service, or from the technological point of view of how is implemented?
From the point of view of how do you consume the SQL Azure service is the same argument that pertains every other aspect of Software as a Service discussion: reduce initial investition cost, scale as you grow, reduce the management and administration overhead, service level agreement on availability, scalability and disaster recoverability, continous upgrade of hardware, no licensing fees and so on and so forth. SaaS it makes a tonne of sense from business point of view for any operation, and specially for start ups. I won't go into more detail as other answers already covered this.
From a technical point of view, SQL Azure is far from an instance exposed on the internet. At PDC 2008 there were some presentations on the internal details of how SQL Cloud was working. SQL Azure exposes a different access model (T-SQL in SQL Azure vs. Containers and Entities in SQL Cloud), but some of the technical details presented about Cloud are probably still valid.
The Cloud had no individual SQL Servers, it is build on a mesh of thousands of SQL engines (code base common with SQL Server 2005, but not actual SQL instances) that cooperate in storing the data and servicing queries.
In Cloud the data (the 'Data Fabric') was partitioned into fragments that were replicated into at least 3 safety copies. If any fragment copy is lost, another the remaining copies are clonning a new copy to bumb up the count of redundand copies back to 3. Each fragment has a master copy that is used both for reads and writes. Each engine is hosting a multitude of fragments, some master some copies. No two copies of the same fragment are ever hosted on the same engine. As updates are done to the master copy, the engine ships the changes over to the fragment redundant copies in real time.
These, and other details about how the 'Data Fabric' is implemented, how the various automation auto-pilot failure detection and similar topics are presented in SQL Services: Under the Hood.
Some of the things have changed for sure with the changes from the SQL Cloud to the SQL Azure, but I'm sure many of the 'under the hood' facts are still valid.
PS: is incredible the amount of spam comments Channel9 is letting in...