Database Reference
In-Depth Information
can achieve a very successful application deployment into the cloud. The purpose of this discussion, and
of Chapter 2, is to get you to think and plan before you deploy, so you take the right approach. The
question is, what is that right approach?
This discussion is really about two things. First, when deciding to move an application to the cloud,
do you move the entire application (meaning, database and app) or just a portion? Second, regardless of
whether you move all or a portion of the database, do you also move the application, or do you keep the
application on-premises? Let's not forget that using SQL Azure doesn't mean you automatically have to
move your application to the Azure platform. You can move your database to the cloud and still host
your application on-premises. As with everything, you have options. Let's discuss the different ways of
hosting your SQL Azure application.
On-Premise Application
On-premise means your application is hosted locally and not in Azure, but your database is in SQL
Azure. Your application code uses client libraries to access one or more SQL Azure databases. Some
companies are reluctant to put business logic or application-specific logic outside of their corporate data
center, and the on-premise option provides the ability to house the data in the cloud while keeping the
application logic local.
Although this is a viable option, limitations are associated with it. For example, only the following
client libraries are supported:
.NET Framework 3.5 SP1 Data Provider for SQL Server (System.Data.SqlClient) or
later
Entity Framework 3.5 SP1 or later
SQL Server 2008 R2 Native Client ODBC driver
SQL Server 2008 Native Client Driver (supported, but has less functionality)
SQL Server 2008 Driver for PHP version 1.1 or later
If your application uses OLE DB, you have to change your application so use one of the client
libraries listed here.
The biggest consideration related to keeping your application on-premise is the cost. Any time you
move data between SQL Azure and your on-premise application, there is an associated cost (currently,
$0.10 in and $0.15 out per GB, or more if your selected geolocation is Asia). If you're using Azure Storage,
there is also the cost of using that storage (currently, $0.15 per GB stored per month). Again, this is per
GB, so the cost is low. An example of an expensive pattern is synchronizing large amounts of data
multiple times per day. But keep in mind that synching even a 50GB database costs only $5.
These costs and limitations shouldn't deter you from using an on-premise solution for your
application. However, let's look at what an Azure-hosted solution provides.
Azure-Hosted Application
Azure-hosted means that your application code is hosted in Windows Azure and your database is in SQL
Azure. Your application can still use the same client libraries to access the database or databases in SQL
Azure. Most companies right now are taking existing ASP.NET applications and publishing them to
Windows Azure and accessing SQL Azure. However, you aren't limited to just web apps: you can use a
Windows desktop app or Silverlight app that uses the Entity Framework and the WCF (Windows
Search WWH ::




Custom Search