Normal vs Cloud / Azure Hosting and the role of SQL Azure vs SQL Server

Question

First of all, let me understand that I am not from the web background, so if any of my ideas on how this works is wrong, feel free to correct me.

Say I have a website that I would like to host on the cloud because

- I don't want to take care of hardware - I want to scale my website as needed 

Now I'm a little confused between the SQL Server role and the SQL Azure role in this case.

General web hosting

When I think of a normal website, I know that I need a host / server that will host my website. The host must support SQL Server . To scale, I will have to host my ASP website / pages on multiple servers. Similarly, if I want to increase my SQL Server , I will have to host it on several servers and you will need to make sure that the data is updated on all servers through some mechanism.

Cloud Computing Hosting

Now I think that I can configure a similar structure on Cloud/Azure . If so, can I use the true capabilities of Cloud in this case?

Or use SQL Azure instead of SQL Server ? What benefit will I get in this case? Will I still be responsible for data expansion and consistency? I know that I can expand the site by setting the number of virtual machines / instances, but what about scaling the database?

Edit Thanks to Florin Dumitrescu terminology I wanted to use was Scaling Out , because I'm more concerned about performance, rather than how large my database is. What worries me more is how the database will scale between different servers / systems to accommodate the load and therefore will lead to better performance.

Answer 1

SQL Azure, as Yossi mentioned, is a database as a service. So you just ask for it to be provided, magic happens, and you have a database that scales from 1 to 5 GB, 10 GB, up to 50 GB (soon there will be 150 GB as declared in SQL PASS). Best of all in SQL Azure: you don’t need to worry about any infrastructure, servers, licensing, etc. You just connect to your connection string. SQL Azure is designed to scale to handle a significant number of concurrent tenants, so you don't have to worry about scaling.

SQL Azure also replicates its data in the data center to provide “solid” storage. You still need to develop a disaster recovery scheme if the data center becomes unavailable (and you can use the Data Sync Service service for this ).

As for the website itself: as you scale to multiple instances, each instance executes the same code and uses the same resources. Taking this step further, you can move your static (non-changing) web content, such as images and CSS, into the Blob repository. This has several advantages over saving them using the website itself:

• Ability to enable content delivery network, a global edge caching service that delivers better performance for your end users.
• Less load on web server instances, as requests for these images will now be routed to the Blob repository, a completely separate URL than your website.
• The ability to update an image or style sheet without redeploying the application - just upload the new file to the Blob repository.

I highly recommend the Learning Kit for the Windows Azure platform , as there are laboratories that tell you the basic principles of all this, with full code samples. This is updated almost monthly, synchronizing with the latest versions of the Windows Azure SDK and tools.

Answer 2

If you host your website in the cloud and you need a database, then SQL Azure is definitely the best option.

SQL Azure is a database as a service, so you create your database and work against it from your code, but do not have to worry about providing information, there are no servers as such, all this takes care of.

From the point of view of the application, it looks and behaves the same as SQL Server, so initially all changes are a connecting line

Answer 3

As noted, SQL Azure addresses your concerns about setting up and maintaining your infrastructure. This is part of Azure’s premise as a whole, which is to provide a platform, not just infrastructure.

The price you pay for this is some of the limitations on features (compared to regular SQL). Size limit (at least until federation is available) and increased latency (since your database does not work on the same server of your application)

Microsoft Teched has an Azure SQL Performance and Resilience Guide , which you should probably look at