Overall Stability, Security and Performance :  A-

Azure definitely confounded some of its harsher critics by registering a very good track record for uptime, performance and most important – security. Since its launch there have been no major security issues and no large outages. I’ve run Azure since April and the only issue was two short periods (under one hour) of sluggish performance while OS patches were being applied, it seems that most users experiences have been similar to mine.

SQL Azure : D

While the performance of SQL Azure has been good, I can only register my bitter disappointment at the progress of adding features. I noted that probably the biggest weakness of SQL Azure at launch was the lack of any backup facility, we were promised two backup functions (continuous and clone) with one to appear in the first half of 2010 but still no sign of anything, no sign of encryption or compressions either. The features that have been added can only be described as basic – such as a 50GB sized database, or  the ability to automatically upgrade to a larger database size (although we still have to execute a TSQL Alter statement for this). 
SQL Azure itself is a solid product but it is still too expensive and lacking in even the basic features SQL Server users require.

Windows Azure Features : C-

Azure is still not heavy in terms of features, which is fine for a product is its first year so it would be merited a B- or C+ had it not been for the omission of .NET 4.0 support (6 months and counting since .NET was released).  Unfortunate for Microsoft the last year has been one of heavy innovation for its main rival – AWS. Most notably, AWS Simple Notification Services (SNS) allows AWS users to send notifications via several formats (even email and SMS) to alert a user of an application of an event (this is a heavily requested feature on Azure but no plans have been confirmed to add it).

Azure Tooling : C+

.NET developers are used to best in class dev tools and so we’d expect great tooling for deploying to Azure. We now have an vastly improved Visual Studio experience which allows for direct deployment  to Azure (which is great since the Azure developer’s portal is still slow and generally a poor user experience). We can also directly connect to SQL Azure databases to view and interact with database objects from SSMS 2008 R2 and generate scripts to create an SQL Azure database. But this is pretty much the minimum we would expect using a Microsoft environment.

In the minus column the Azure portal is still slow and lacking in features, monitoring of the cost is very basic and the are no tools for monitoring the   various running instances of an Azure service. Also, migration tools are pretty lacking – the SQL Azure migration is good to troubleshooting a migration to SQL Azure but won’t be able to solve many of the incompatibilities. No tool exists for migration an ASP.NET app (there are several tutorials on migration in which the process looks relatively simple but there are enough gotchas to make the migration of a reasonably sized ASP.NET app a real headache).

Pricing : D

I’ve given a D for pricing as it is the one area where improvement could easily have been made. Probably the most persistent complaint about Azure is the high cost of the entry. With a single SQL Azure database and only a single compute instance an Azure plan will cost $60 – $90 per month depending on any discounting given if you are a member of BizSpark or MSDN etc. Even worse if you need to rely on Azure’s 99.95% uptime SLA you are required to have 2 compute instances which will comfortably bring the cost to over $100 (imagine your hosting company informing you that you needed a second server if you wanted to have good uptime ). This is a relatively high barrier to entry for small developers who are building new apps which will only initially use a fraction of the small compute instance and the 1GB SQL Azure database allocation. AWS meanwhile now offers an ultra-small instance which costs only $15 per month and in addition they are offering a full free year to new users.

I would have given an E except for the fact that Azure pricing matches AWS whilst offering a lot more.  The Azure platform handles all the OS patching, scaling and security without the need for user intervention. AWS by contrast with its infrastructure as a service model merely provides the OS and offers some tools the user can implement (such as the elastic load balancer) to manage scaling, patching and security updates is left to the user.

Conclusion

Overall the grades might not have been too high but it is definitely the grade for stability, security and performance which is the most important since a poor performance would surely mean the death of the Azure platform and the only one area where Azure should definitely have been better is in pricing. We are definitely lacking in tools and features (especially for SQL Azure) but since it is just a year we shouldn’t be too demanding – the real test of Azure will be whether it can innovate over the next 1 -2 years.

For this demo we will use SQL Server Management Studio (SSMS) to generate the SQL scripts and
migrate an existing database from SQL Server 2008 to  SQL Azure. It should be noted that there are several tools such as the SQL Migration Wizard for assisting in the migration, but in this article we will look at performing a manual migration.

Since SQL Azure is built from SQL Server 2008, the database should first be migrated to SQL Serer 2008 if necessary (note – it is not necessary to update to 2008 R2).

1. Open SQL Server Management Studio (SSMS), right-click on the database node of the database to be migrated (AdventureWorks for this demo) and select Tasks > Generate Scripts , then select the database to be migrated and click Next:
   
2. In the Choose Script Options page, we need to configure the script to comply with the restrictions of SQL Azure, so make the following changes:
   • Convert UDDTs to Base Type: Set this  to true as SQL Azure does not support user-defined types. UDDT’s need to be converted into SQL Azure portable types.
   • Script extended properties: Set to false as SQL Azure does not support extended properties.
   • Script USE DATABASE: Set to false as SQL Azure does not support the USE statement.
   • Script Data: Set to false since we are not migrating the data right now.
3. In the Choose Object Types page – select all the objects except User Defined Data Types and click Next:
   
4. In a succession of screens you will be prompted to select the Stored Procedures, Views, Tables etc to be migrated (depending on which objects are in your database). Click Select All then Next for each.
5. Finally at the Output Option page select where the script should be generated (in this example I have elected to have the script generated in a new query window):
   
6. Click Next and SSMS will direct you to the Summary page before generating the scripts in a new SQL script window. The Generate Script Success screen shows the progress and results of the migration on the database objects (see below). Copy the script generated to the clipboard.
   
7. Log in to the Azure platform portal at https://sql.azure.com/ and create a target database on the online portal (simply click Create Database after navigating to the the SQL Azure tab and then select the database size).
8. Close and re-open SSMS to connect to SQL Azure and view your database (see Connect to SQL Azure from SSMS for details if neceesary) . Note – SSMS in SQL Server 2008 R2 can view the SQL Azure objects and should be used whenever connecting to SQL Azure.
9. Copy the script into a new script window in SSMS. Before we run the script against the target SQL Azure database we still need to make some modifications to the script:
   • SQL Azure’s first release does not support partitions. Therefore the KEY constraint statement for the table-creation scripts has to be removed and replaced by a separate script. For example, in the original script SSMS generated for creating a data table there are KEYconstraints such asPRIMARY KEY CLUSTERED
     (
     [TerritoryID] ASC
     )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
     ) ON [PRIMARY]

     This needs to be replaced with a separate ALTER TABLE Script to Assign a Key to a Table, such as:

     ALTER TABLE [Table_Name]
     ADD CONSTRAINT ID_PK PRIMARY KEY (Primary_Key)

   • If there are any CREATE NONCLUSTERED INDEX statements in the script, these will need to be modified. For example remove the bold type text from the below script section:CREATE NONCLUSTERED INDEX [IX_UserTable_FirstName] ON [dbo].[UserTable]
     (
     [FirstName] ASC
     )WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF,ONLINE = OFF) ON [PRIMARY]
     GO

That’s it, now run the script against the SQL Azure database (ie click New Query in SSMS, select the target SQL Azure database from the dropdown database listing  and click Execute).

It should be noted that this is as of SQL Azure Update 1 (February 2010) , SQL Azure is currently developing rapidly and not all the inconsistencies with SQL Server are well documented.

This will be sufficient for your Azure apps to run bu you will also need to access the server for development purposes and so additional rules are required. Simply click Add Rule, name the rule and set the IP address range for the rule. In this example I have set an extremely strict rule to only allow my IP access to the database. To turn off the firewall enter the range 0.0.0.0 to 255.255.255.255 but this is obviously not recommended.
Bear in mind your local development environment may also have a firewall and to connect to the SQL Azure database you must have enable TCP communication on TCP port 1433.

The firewall can also be manipulated by executing TSQL against the Master database (you will obviously have to configure a firewall rule allowing a connect from the source of the TSQL first).

View Firewall Rules

The  sys.firewall_rules view contains the ?? id, name, start_ip_address, end_ip_address, create_date and modify_date for the firewall rules.

--Select all firewall rules
select * from sys.firewall_rules

Add/Update Firewall Rules

Use the sp_set_firewall_rule stored procedure to add or update firewall rules, with name, start_ip_address, end_ip_address as the parameters.

--Create a firewall rule
exec sp_set_firewall_rule N'azureSupDev','0.102.129.120','0.102.130.110'

--Update a firewall rule
exec sp_set_firewall_rule N'azureSupDev','0.102.129.120','0.102.130.135'

Delete Firewall Rules

Use the sp_delete_firewall_rule stored procedure to delete firewall rules, with name as the only parameter:

--Delete a firewall rule
exec sp_set_firewall_rule N'azureSupDev','0.102.129.120','0.102.130.135'

The closest to an inbuilt backup functions is support for the TSQL Database Copy command which produces a transactionally complete copy of a database.

Coming in 2010, Azure will deliver two backup methods – Clone and Continuous Backup. Clone (targeted for release in H1 2010) allows for a transactionally consistent ‘clone’ to be made of a database, once a clone is created it is a totally separate database with no relations to the ‘parent’ database. Continuous Backup (targeted for release in H2 2010) is similar to a mirror and is configured with a retention period and a lag time. Continuous Backup copies will be read-only. These will be be add-ons to the standard SQL Azure service and will incur an additional fee which was has not yet been announced.

• BCP using the .exe bulk load/export tool.
• SSIS
• Bulk API’s in ADO.NET and ODBC (see below).
• Third Party Tools
• Sync Framework

BCP

BCP is probably the fastest way to move the data. BCP is a command line tool introduced with SQL Server 2005 SP1 which allows for copying data in and out of SQL Server. The tool uses standard TSQL Syntax conventions.
// BCP example

SET SRV=aserver.database.windows.net

SET LOGIN=judo@someserver

SET PW=something

SET S_DR=C:flats

bcp TPCH2.dbo.supplier in %S_DR%supplier.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.nation in %S_DR%nation.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.region in %S_DR%region.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.customer in %S_DR%customer.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.part in %S_DR%part.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|“

bcp TPCH2.dbo.supplier out %S_DR%supplier.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.nation out %S_DR%nation.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.region out %S_DR%region.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.customer out %S_DR%customer.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.part out %S_DR%part.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

ADO.NET Bulk Copy API:

// Bulk data import

using (SqlBulkCopy bulk = new SqlBulkCopy(new SqlConnection(conn))

{

DestinationTableName = “dbo.data”,

BatchSize = 2000, // Transaction size (length)

BulkCopyTimeout = 10000, // Transaction timeout

NotifyAfter = 1000, // Progress callback

})

{

bulk.SqlRowsCopied += new SqlRowsCopiedEventHandler(

myProgressCallback);

bulk.WriteToServer(sourceDataReader);

}

Third Party Tools

Currently the primary third party tool for migration is the SQL Azure Migration Wizard

In addition there is inbuilt DOS protection, if there are many failed attempts to access a SQL Azure database the requesting IP is disallowed for a period of time. Thus if you make several incorrect login attempts you may be locked out for a short period.

As at launch (January 2010) SQL Azure will disconnect any idle sessions after 5 minutes, it will also kill any long running transactions which last over 5 minutes (Microsoft has pledged to adapt this restriction in future and attempt to distinguish between genuine long running transactions and transactions which are not operating correctly). SQL Azure will implement resource throttling if a process generates excessive CPU or I/O load. The exact throttle thresholds are not disclosed.

There is a subtle difference in connecting compared with SQL Server. When connecting to SQL Server you are first connected to the server and through the server to the database, in Azure you are directly connected to the database. This means that there is no support for context switching using the USE keyword (in SQL Server this allowed the Server to direct a request to a database determined at run-time).

Database

First you need to create a database. You need to be logged in to the Master database to create a database.

CREATE DATABASE AdventureWorks2008

After creating the database, you need to log into the database with the created database credentials.

Schema, UDF and UDT

Schema , UDF and UDTs will be created without any issues. However, if you generate the script from the AdventurkWorks2008 database there will be entries for stored procedure sp_addextendedproperty.

Table & DML Triggers

There are a few limitations in the CREATE TABLE statement when it comes to SQL Azure which are highlighted in the following image.

You will need to remove these tags and columns to create tables in SQL Azure. As you can see in the above image, ROWGUIDCOL, xml and hierarchyid data types are not supported.

Triggers will be created but you shouldn’t use columns with more than two parts.

If you run this statement you will receive following error.

Deprecated feature ‘More than two-part column name’ is not supported in this version of SQL Server.

In the Update statement above, RevisionNumber is referred as [Purchasing].[PurchaseOrderHeader].[RevisionNumber] which will not be supported by SQL Azure.

View

Views don’t have major issues except that the above mention column types are not supported.

Stored Procedures

Store procedures behave same as views.

DDL Triggers

DDL Triggers can be created but with a major limitation – the EVENTDATA() function is not supported in SQL Azure (the EVENTDATA() function used to capture event information).