Born only a few years ago, cloud computing is capturing the imagination of startups and large corporations alike. In its simplest form, cloud computing is an evolution of traditional hosting models; as such, it isn't necessarily a new technology. Rather, it's a new concept that offers new opportunities and challenges not found in existing business models. Much as agile programming provided a new software development paradigm, cloud computing provides a new delivery model for Internet-based solutions.
Let's begin with what cloud computing has to offer compared to traditional hosting services. The following capabilities are generally expected from large cloud-computing providers:
Automatic and unlimited scalability. The promise that if your service needs more resources, more resources will be provisioned automatically or with limited effort. For example, if you deploy a web service, and you experience a sudden surge in processing needs, your services will automatically expand to additional servers to handle the temporary surge and contract to fewer servers during off-peak activity.
Unassisted deployment. The promise that if you need to deploy additional services or databases, you don't have to call anyone or open a service ticket. The cloud service provider will give you the necessary tools to perform self-service.
Built-in failover. The promise that if one of your servers fails, no one will ever notice. For example, if the server on which your service is installed crashes, a new server immediately takes over.
Grow as you need; pay for what you use. The promise that you only pay for the resources you use. For example, if your service experiences a sudden surge in processing needs for a day, but it scales down to its usual usage for the rest of the month, you're only charged marginally more than usual for the temporary surge.
Smaller companies, including startups, are building services that can run in the cloud, whereas larger companies are investing in building cloud-enabled infrastructure. Some corporations are building consulting services and offering to assist customers implement cloud-enabled solutions; others, like Microsoft, are investing in the core infrastructure and services that make the cloud a reality.
Microsoft has traditionally been a software provider, but the company has slowly moved closer to hardware solutions over the years. In the late 1990s, Microsoft engaged with Unisys, HP, Dell, and other hardware manufacturers to provide highly available Windows-based platforms (Windows Data Center Edition). At the same time, Microsoft invested significant resources to build its Microsoft Systems Architecture (MSA). This program was designed to help corporations plan, deploy, and manage Microsoft-based IT architecture. These initiatives, along with many others, helped Microsoft develop strong knowledge capital around highly available and scalable architectures, which are a prerequisite for building cloud computing platforms.
Amazon entered the cloud computing space with its Elastic Compute Cloud (EC2) services in 2005. A few years later, Google and IBM joined forces to enter this market, and Microsoft announced many of its cloud computing plans during 2009, including the Azure platform. As part of its Azure platform, Microsoft delivered a very unique component in its cloud computing offering: a transactional database called SQL Azure.
Generally speaking, cloud computing comes in one of three flavors:
SaaS: software as a service. This delivery platform is usually in the form of web applications that are made available on the Internet for a fee. This model has been around for a few years.
PaaS: platform as a service. This service offers a computing platform that facilitates the use and deployment of other services and scales according to the general expectations of cloud computing, such as scalability and pay-as-you-go.
IaaS: infrastructure as a service. This offering provides the necessary infrastructure that offers the scalability typically associated with cloud computing.
SaaS, PaaS, and IaaS are considered the fundamental building blocks of cloud computing. Other acronyms are being manufactured to depict new flavors of cloud computing, such as desktop as a service (DaaS), hardware as a service (HaaS), and even research as a service (RaaS). Pretty soon, the entire alphabet will be consumed in describing the many flavors of services that can be created in the cloud.
Let's discover the three major components of the Microsoft Azure platform, also called the Azure services: Windows Azure, Windows Azure AppFabric, and SQL Azure. All three offer unique capabilities that provide a complete array of services needed to build highly scalable and secure solutions:
Windows Azure. A collection of virtual Microsoft operating systems that can run your web applications and services in the cloud. For example, you can create a web service that converts US dollars to Euros; then, you can deploy the service on Windows Azure and allow it to scale as needed. Note that Windows Azure can run .NET applications and other platforms as well, including PHP.
Windows Azure AppFabric. A set of services that provide core capabilities such as federated identity for access control, and a service bus for a messaging-based subscriber/publisher topology.
SQL Azure. Microsoft's transactional database offering for cloud computing based on Microsoft SQL Server 2008. For example, you can store your customer database in the cloud using SQL Azure and consume customer data using services deployed in Windows Azure.
Figure 1-1 shows a simplified corporate environment connecting to the Microsoft Azure platform and consuming all three services. This diagram is overly simplified, but it conveys an important message: Microsoft Azure is designed to extend a corporate environment securely for web applications, services, messaging, and data stores.
One of the fundamental questions that's frequently asked is, "Why?" Who's interested in developing applications in Windows Azure in the first place? To answer this question, let's look at the evolution of web platforms.
About 15 years ago, when the public Internet was all about bulletin board systems (BBBs), Gopher services, and $500 9600-baud modems, the question was, "Will the Internet stick as a technology?" That question has been answered, but many new concepts have grown since then, including web sites, hosting centers, and SaaS.
This evolution relies on a common theme: decoupling. BBSs decoupled public information from libraries; web sites decoupled user interfaces from computers; hosting centers decoupled hardware from a company's own infrastructure; and SaaS decoupled complex applications from corporate computers.
Cloud computing on Microsoft Azure is a natural evolution of computing flexibility in which the actual physical storage and implementation details are decoupled from the software solution. For example, deploying services in Windows Azure doesn't require any knowledge of the machine running the service or any of the core services (IIS version, operating system patches, and so on). You may never know which machine is running your software. Connecting to a Windows Azure server is performed through logical names, just like connecting to SQL Azure.
The ability to disassociate machines from data and services is very powerful in itself. Although it's still an early-stage platform, Microsoft's Azure environment allows multiple business scenarios to flourish, including these:
Seasonal applications. Developing web sites or services that have a tendency to grow and contract over time provides potential savings opportunities because cloud computing uses a pay-as-you-use model.
Short life span. Development of prototypes or applications with short lifespans is also attractive, such as event-registration sites. You can also build development and test environments for remote teams.
Split storage. Certain applications need to keep storage in a safe location but may not require frequent access, or may require high availability. Designing or modifying an application so that the data is stored locally and in SQL Azure (or other data-storage formats) may make sense.
Small companies and ISVs. Smaller companies that can't afford large and complex infrastructure to start their business can take advantage of the financial and inherent infrastructure benefits of Microsoft Azure. Independent software vendors (ISVs) can also benefit from cloud computing. For example, an ISV can use SQL Azure to store application logs or centralize reporting features from multiple disconnected locations.
See Chapter 2 for more information about design patterns and application scenarios that use the Azure platform.
In order to provide high availability, Microsoft established regional data-center operations that allow customers to select geographically dispersed services. When you create your Azure servers, you need to specify which geographic location the servers should be provisioned in. This feature is called Windows Azure geolocation.
Initially, it may be tempting to choose your company's geographic location for improved performance. However, if the availability of your Azure services is more important than response time, you may need to pick another location. When selecting a geographic location, make sure to consider the following:
Performance. When your data is closer to your users, network latency may be noticeably lower, improving customer experience.
Disaster recovery. If ensuring the availability of your cloud platform is important, you may want to disperse your services and data across multiple regions.
Legal factors. Consider the type of information that will be stored in the cloud, and ensure that you aren't bound by specific regulations and mandates that may prevent you from selecting remote geographic locations.
At the time of this writing, you can select from one of the following geographic locations, each of which is supported by a regional data center:
In addition, you can create an affinity group that lets you keep certain Azure services together. Such a group creates a geographic dependency between Windows and data services deployed in the Microsoft Azure platform. If Microsoft is obligated to move a service to another geolocation for regulatory reasons, the related services will likely move along. For example, if you develop an Azure service that depends on a SQL Azure database, you may want to ensure that they both reside in the same geolocation and that they belong to the same affinity group.
Additional locations will be added over time. As a result, you may need to reevaluate on a regular basis whether a service is deployed in the most appropriate geographic location.
As you can imagine, cloud computing is all about storing data in a simple yet scalable manner. The Microsoft Azure platform doesn't disappoint and offers a variety of storage models that you can choose from. This section summarizes the four ways you can store your data in Azure; three of these approaches are considered part of the Azure services.
Figure 1-2 provides an overview of the storage options and the available access methods. The set of storage options provided by Windows Azure is referred to as Windows Azure storage, which includes blobs, tables, and queues. Windows Azure storage can be accessed directly from a corporate environment using HTTP/S calls, providing a simple hook into the Microsoft Azure platform. In addition to using Windows Azure storage, consumers can make requests directly to a SQL Azure database using ADO.NET or ODBC, because SQL Azure supports the Tabular Data Stream (TDS) protocol that SQL Server uses. As a result, applications and services connecting to a SQL Server database can just as easily connect to a SQL Azure database.
Following are further details of the four storage types:
Azure services storage. The Azure services offer three distinct storage models that are tailored to specific needs:
Table. A named value-pair storage that allows you to store very large amounts of data. This storage model includes automatic load balancing and fail-over. It's called a table because you can store multiple values in each row. However, this isn't a transactional storage mechanism; no indexing or table joins are possible. Also, the columns defined in a table have storage limitations. For example, a string data type is limited to 64KB.
Blobs. An interface to store files, with a maximum limit of 50GB of storage for each blob. You can easily access blobs using a straight HTTP request through a Representational State Transfer (REST)) call.
Queue. A highly available mechanism for storing messages for consumption by other applications or services. A typical usage of queues is to send XML messages. Certain limitations apply to queues, but you can access queues through REST as well.
SQL Azure. SQL Azure is a transactional database that provides familiar data access through ADO.NET or other providers and gives you the ability to manipulate the data using standard T-SQL statements. Databases in SQL Azure are limited to either 1GB or 10GB, depending on the edition selected.
Table 1-1 summarizes the current characteristics of these data-storage options available in the Azure platform.
As you've seen, SQL Azure is a relational database engine based on SQL Server technology. It supports many of the features of SQL Server including tables, primary keys, stored procedures, views, and much more. This section gives a brief primer to get you started using SQL Azure. You see how to register for Azure, how to create a database and then an account, and how to log in.
To register for Windows Azure, visit the Pricing page on the Windows Azure web site: http://www.microsoft.com/windowsazure/offers/. Figure 1-3 shows some of the available options.
From this page, you have the ability to pick the offer that best fits your profile and needs. After you've chosen your preferred plan, click Buy, and follow the onscreen instructions. When this is complete, you receive an e-mail with instructions on how to configure your Windows Azure platform.
To access the Azure portal, you can use one of the following URLs. They all point to the same master portal:
http://sql.azure.comhttp://appfabric.azure.comhttp://windows.azure.com
For step-by-step instructions on how to create your Azure account, see Chapter 3. When you create your Azure account, you're required to create an administrator account for SQL Azure. This account is used to create databases and other logins.
When the SQL Azure server is created, the master database is provisioned automatically. This database is read-only and contains configuration and security information for your databases. You can then create your user databases. You can either use the SQL Azure portal or issue a T-SQL statement against the master database.
One way to create a database is to do so from the SQL Azure portal. From the Server Administration screen, click Create Database at the bottom of the screen, as shown in Figure 1-4.
A small window opens, as shown in Figure 1-5. Enter a database name, select a database edition (Web or Business), specify the size of your database, and click Create. You can choose the Web edition if 1GB or a 5GB is sufficient for you. If you need to create larger databases, choose the Business edition, which lets you select a size between 10GB and 50GB, in 10GB increments.
Note
The monthly fee varies, depending on the size of the database. See the additional information later in this chapter and the complete pricing information on Microsoft's web site: www.microsoft.com/azure.
Creating a new database using a T-SQL command is straightforward. Because a database in SQL Azure is managed by Microsoft, only a few options are available to you. In addition, you must be connected to the master database to create new databases.
To create a new database, log in using the administrator account (or any user with the dbmanager role), and run the following T-SQL command:
CREATE DATABASE mydatabase (MAXSIZE = 1 GB)
As previously discussed, the size of the database can be 1GB, 5GB, or 10GB–50GB. If the MAXSIZE parameter isn't defined, the size of the database is set to 1GB.
SQL Azure implements a firewall on your behalf. That's a benefit that helps protect your database. Indeed, the default firewall rule is that no one can connect. Allowing no connections by default is a good security practice, because it forces you to think through what IP addresses you wish to allow in.
Following these steps to add an IP address (or IP range) for a computer that needs access to the SQL Azure server:
On the Server Administration screen, click the Firewall Settings tab. This tab shows the firewall rules that are currently defined (see Figure 1-6).
Click Add Rule. Specify a name for this rule, and enter your IP address on the first line of the IP Range. Specify the same IP in the
tofield to limit access to a single IP (see Figure 1-7).
If for some reason the firewall rules aren't correctly configured, you see an error message saying so. Figure 1-8 shows the error message you get using SQL Server Management Studio if the firewall rules don't allow you to connect. The error message looks like a login failure, but the description of the error clearly indicates that the client with the given IP address isn't allowed to access the server.
Note
When you're creating a firewall rule, you may need to wait a few minutes for the rule to take effect.
You can also view and edit firewall settings directly using T-SQL by connecting to the master database with the administrator account and using the following objects:
sys.firewall_rulessp_set_firewall_rulesp_delete_firewall_rule
Now that you've configured your SQL Azure database, the fun can begin!
Follow these steps to connect to your SQL Azure database using SQL Server Management Studio:
You need to obtain the fully qualified server name of the SQL Azure database. Figure 1-9 shows the server information on the SQL Azure portal. The fully qualified server name is located above the Reset Password button.
Start SQL Server Management Studio. Click the Cancel button in the Login screen.
Note
If you're using SQL Server Management Studio for SQL Server 2008 R2, you can log in using the first Login window. However, if you're using a previous version of SQL Server Management Studio, you need to click Cancel in the first Login window. The instructions provided in this section work for both editions.
Click the New Query button, or press Ctrl + N. A new Login screen opens (see Figure 1-10). In this window, enter the following information:
By default, clicking Connect authenticates you against the master database. If you want to connect to another database, click Options and type the desired database name in the "Connect to database" field, as shown in Figure 1-11. Note that you can't select the database name; the database name must be typed.
When you're ready, click Connect. A new query window opens, and you can execute T-SQL commands against your SQL Azure database.
Note
After you connect to a database, the only way to use another database is to re-establish a connection and type the database name in the "Connect to database" field. The USE command doesn't work against SQL Azure to switch database contexts. Because a database can be physically located on any server, the only practical way to switch databases is to reconnect.
Figure 1-12 shows the query window connected to SQL Azure, on which a simple command has been executed.
With SQL Azure, the process of creating logins and users is mostly identical to that in SQL Server, although certain limitations apply. To create a new login, you must be connected to the master database. When you're connected, you create a login using the CREATE LOGIN command. Then, you need to create a user account in the user database and assign access rights to that account.
Connect to the master database using the administrator account (or any account with the loginmanager role granted), and run the following command:
CREATE LOGIN test WITH PASSWORD = 'T3stPwd001'
At this point, you should have a new login available called test. However, you can't log in until a user has been created. To verify that your login has been created, run the following command, for which the output is shown in Figure 1-13:
select * from sys.sql_logins
If you attempt to create the login account in a user database, you receive the error shown in Figure 1-14. The login must be created in the master database.
If your password isn't complex enough, you receive an error message similar to the one shown in Figure 1-15. Password complexity can't be turned off.
Note
Selecting a strong password is critical when you're running in a cloud environment, even if your database is used for development or test purposes. Strong passwords and firewall rules are important security defenses against attacks to your database. Chapter 4 reviews security in depth.
You can now create a user account for your test login. To do so, connect to a user database using the administrator account (you can also create a user in the master database if this login should be able to connect to it), and run the following command:
CREATE USER test FROM LOGIN test
If you attempt to create a user without first creating the login account, you receive a message similar to the one shown in Figure 1-16.
So far, you've created the login account in the master database and the user account in the user database. But this user account hasn't been assigned any access rights.
To allow the test account to have unlimited access to the selected user database, you need to assign the user to the db_owner group:
EXEC sp_addrolemember 'db_owner', 'test'
At this point, you're ready to use the test account to create tables, views, stored procedures, and more.
Note
In SQL Server, user accounts are automatically assigned to the public role. However, in SQL Azure the public role can't be assigned to user accounts for enhanced security. As a result, specific access rights must be granted in order to use a user account.
SQL Azure is a pay-as-you-go model, which includes a monthly fee based on the cumulative number and size of your databases available daily, and a usage fee based on actual bandwidth usage. However, as of this writing, when the consuming application of a SQL Azure database is deployed as a Windows Azure application or service, and it belongs to the same geographic region as the database, the bandwidth fee is waived.
To view your current bandwidth consumption and the databases you've provisioned from a billing standpoint, you can run the following commands:
SELECT * FROM sys.database_usage -- databases defined SELECT * FROM sys.bandwidth_usage -- bandwidth
The first statement returns the number of databases available per day of a specific type: Web or Business edition. This information is used to calculate your monthly fee. The second statement shows a breakdown of hourly consumption per database.
Figure 1-17 shows a sample output of the statement returning bandwidth consumption. This statement returns the following information:
time. The hour for which the bandwidth applies. In this case, you're looking at a summary between the hours of 1 AM and 2 AM on January 22, 2010.
database_name. The database for which the summary is available.
direction. The direction of data movement. Egress shows outbound data, and Ingress shows inbound data.
class. External if the data was transferred from an application external to Windows Azure (from a SQL Server Management Studio application, for example). If the data was transferred from Windows Azure, this column contains Internal.
time_period. The time window in which the data was transferred.
quantity. The amount of data transferred, in kilobytes (KB).
Visit http://www.microsoft.com/windowsazure for up-to-date pricing information.
As you've seen so far, creating databases and users requires manual scripting and switching database connections. The fundamental differences between SQL Server and SQL Azure lie in the basic design principals of cloud computing, in which performance, ease of use, and scalability must be carefully balanced. The fact that user databases can be located on different physical servers imposes natural limitations. In addition, designing applications and services against SQL Azure requires you to have a strong understanding of these limitations.
Chapter 4 covers security in depth, but the following list summarizes important security considerations before you deploy your SQL Azure databases. From a security standpoint, you need to consider the following constraints:
Encryption. Although SQL Azure uses SSL for data transfers, it doesn't support the data-encryption functions available in SQL Server. However, SQL Azure provides support for the existing hashing functions.
SSPI authentication. SQL Azure only supports database logins. As a result, network logins using Security Support Provider Interface (SSPI) aren't supported.
Connection constraints. In certain cases, the database connection is closed for one of the following reasons:
Excessive resource usage
Long-running query
Long-running single transaction
Idle connection
Failover due to server failure
Disallowed user names. Certain user names can't be created for security reasons:
sa
admin
administrator
guest
root
Login name. In certain cases, you may need to append the server name to the login name to correctly log in, in this format: [loginName]@[servername]. So, avoid using the arrobas character (@) in login names.
TCP port 1433. Only TCP Port 1433 is allowed. It isn't possible to define another listening port for SQL Azure.
Backing up your SQL Azure database is somewhat different from backing up traditional SQL Server databases. You can't back up a SQL Azure database in the traditional sense, nor can you restore a SQL Server database in SQL Azure. You do, however, have the ability to create a transactionally consistent clone of a SQL Azure database. You can expect the following regarding backups:
Backup/Restore operations. These operations aren't available. In addition, you may not attach or detach a SQL Azure database.
Clone operations. You may create a clone of a SQL Azure database into another one using the
CREATE DATABASEstatement.Log files. You can't access the database log files, nor can you create a log backup.
Certain objects available in SQL Server aren't available in SQL Azure. If your applications depend heavily on these features, you may have difficulty using SQL Azure, and you may need to rethink your application design to accommodate these limitations. The following are some of the limitations that currently apply to SQL Azure:
CLR. The .NET CLR isn't available in SQL Azure. As a result, you can't create extended stored procedures or extended functions.
System functions. SQL Azure supports many system functions, including Aggregate functions and Ranking functions. However, SQL Azure doesn't support RowSet functions, including these:
OPENQUERYOPENXMLOPENROWSETOPENDATASOURCE
System stored procedures. Only a small subset of system stored procedures are available in SQL Azure, in the following categories:
Catalog stored procedures
Database engine stored procedures
Security stored procedures
System views. A subset of system views is available; you can access some of them from the master database and others from user databases. The following are some of the system views available (for a complete list, refer to the online MSDN library for SQL Azure):
Heap tables. SQL Azure doesn't allow the use of heap tables. All tables must have a primary |key.
In addition to the limitations outlined so far, additional components and options offered by SQL Server aren't available in SQL Azure. For the most part, these limitations shouldn't affect your application designs, but they're good to keep in mind:
Maximum number of databases. You can create no more than four user databases.
Distributed transactions. Although SQL transactions are supported, distributed transactions aren't supported across SQL Azure databases.
Collation. SQL Azure only supports collation at the column level, or using an expression at execution time. Server- and database-level collations can't be changed and are set to
SQL_LATIN1_GENERAL_CP1_CI_AS.English language. SQL Azure only supports the English language.
Database size. You can only create databases of specific sizes, as outlined previously.
Database file placement. You can't choose how the database files are deployed physically; you can't control filegroups, either. This is handled automatically by the Microsoft data center for optimum performance.
Trace flags. Trace flags aren't available.
SQL Server configuration options. None of the general SQL Server options are available, including CPU and I/O affinity.
Service Broker. The Service Broker isn't available.
Global temporary tables. The global temporary tables aren't available. However, you can use local temporary tables.
SQL Server Agent. The SQL Server Agent isn't available.
You should also know that accessing SQL Azure can only be performed using specific libraries. This may be relevant if you don't use ADO.NET in your programming stack. For example, older versions of Delphi can't connect to SQL Azure. Here is a summary of the supported data libraries:
TDS version 7.3. Any client using a TDS version prior to 7.3 isn't supported.
OLE DB. Connecting with OLE DB isn't permitted.
Drivers and libraries. The following drivers and libraries are allowed:
.NET Framework Data Provider for SQL Server from .NET 3.5 SP1
SQL Server 2008 Native Client ODBC driver
SQL Server 2008 driver for PHP version 1.1
This chapter focused on a fast-track overview of SQL Azure by providing a high-level introduction to cloud computing and how Microsoft is delivering its cloud offering. You also learned the major steps involved in creating an Azure account and how to get started in SQL Azure. You saw some important limitations of the SQL Azure platform, but keep in mind that Microsoft is releasing new versions of its cloud database every few months; as a result, some of these limitations will be lifted |over time.