Databases Reference
In-Depth Information
Don't get the idea that moving an on-premises application to the cloud automatically results in security issues
and a loss of performance—that isn't the case. With planning and the right approach, you 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 (that is, the database and the 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 Database 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 Database application.
On-Premises Application
On-premises
means your application is hosted locally and not in Windows Azure, but your database is in a SQL
Database instance. Your application code uses client libraries to access one or more SQL Database instances. Some
companies are reluctant to put business logic or application-specific logic outside of their corporate data center, and
the on-premises 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 with less functionality)
•
SQL Server 2008 Driver for PHP version 1.1 or later
If your application uses OLE DB, you have to change it to use one of the client libraries listed here instead.
The biggest consideration related to keeping your application on-premises is the cost. Any time you move data
between SQL Database and your on-premises application, there is an associated cost for inbound data transfers (at
the time this topic went to press, $0.05 - $0.12 per GB for US and Europe, $0.12 - $0.19 for all other areas). If you're
using Azure Storage, there is also the cost of using that storage (currently, $0.037 - $0.093 per GB). 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 less than a few dollars.
These costs and limitations shouldn't deter you from using an on-premises 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 Database.
Your application can still use the same client libraries to access the database or databases in SQL Database. Most
companies right now are taking existing ASP.NET applications and publishing them to Windows Azure and accessing
SQL Database. 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 Communication Foundation) Data Services client to access
SQL Database as well. Again, you have plenty of options.
The benefit of using an Azure-hosted solution is the ability to minimize network latency of requests to the SQL
Database instance. Just as important is the fact that you're cutting the costs of data movement between SQL Database
and the application. As long as your Windows Azure and SQL Database are in the same subregion, bandwidth usage
between SQL Database and Windows Azure is free.
