The following describes my experience trying to get raya running on Windows Azure based on the July 2009 CTP of Windows Azure.
Task List
- Add Blob support to allow uploaded photos to be stored in Azure Blobs
- Add support for Azure Storage Tables to replace all SQL database operations
Just 2 easy tasks... 2 easy and loooong tasks. Luckily the SDK abstracts away some of the nitty gritty stuff and lets you focus on the tasks at hand. The StorageClient project that comes with the SDK is used to handle all operations related to storage, eg. create, add, delete and modify Blob and Table entries.
Azure Blob Storage
For raya, the Blob Storage is to store uploaded photos. Only files that are uploaded to the site during runtime would normally require the use of Blob Storage. Files that are included at deployment does not require the use of the Blob Storage, e.g. javascript or css files. Just make sure you set these files as "Content", otherwise they will not be included in the deployment package. One tool that I found useful while developing is the Azure Storage Explorer. It allows you to view your blobs and tables both in your local development storage and in the cloud.
To use the Blob Storage, you will need to create a Blob Container which you can then populate with items. In my case, a Blob Container called "photos" is created and populated with images.
The methods use to create, add, delete, get and to get the Uri location of these uploaded images can be viewed here.
Optimally, Azure queues should be used to do some task asynchronously. In raya, the creation of thumnails is done when the the user uploads a photo. The process of thumbnailing the photo should have been done in a queue. A good example of how Azure queues are used for this purpose can be found in the project PhluffyFotos.
Azure Table Storage
The following is from the Windows Azure Tables whitepaper and describes the Azure Data Table Model.
| Storage Account |
An application must use a valid account to access Windows Azure Storage. |
| Table |
contains a set of entities. Table names are scoped by the account. An application may create many tables within a storage account. |
| Entity (Row) |
Entities (an entity is analogous to a "row") are the basic data items stored in a table. An entity contains a set of properties. Each table has two properties that form the unique key for the entity. |
| Property (Column) |
This represents a single value in an entity. Property names are case sensitive. A rich type set is supported for property values |
| PartitionKey |
The first key property of every table. The system uses this key to automatically distribute the table’s entities over many storage nodes. |
| RowKey |
A second key property for the table. This is the unique ID of the entity within the partition it belongs to. The PartitionKey combined with the RowKey uniquely identifies an entity in a table. |
| Timestamp |
Every entity has a version maintained by the system. |
| Partition |
A set of entities in a table with the same partition key value. |
The Table Storage is not a relational database, the relational database functionality is to be provided by SQL Azure which is a separate service. The per hour cost for SQL Azure is a bit more expensive than that for Azure Table Storage. Wherein lies the problem of migrating your LINQ to SQL queries to support the new structure... it just takes awhile. Yes, you can still use LINQ but you need to enumerate your LINQ queries first and then work on the results. Therefore, the following are some of the methods that will not work in your initial LINQ queries to the database.
- Join()
- Contains()
- Orderby()
- Take()
- Skip()
- Count()
- ToString()
Fortunately, you can still use the above functions while enumerating through the results, ie. LINQ To Objects still works fine. Therefore, you will need to migrate any existing methods that are structured with the above functions. A better way would probably to create an abstraction layer that supports both Azure Table Storage and SQL Server.
Additionally, you will need to create your DataContext. An example is viewable here.
Gotchas
The following are some gotchas when developing under Windows Azure
- When developing locally, don't forget to create the local development storage which actually uses SQL Express to simulate the Table Storage. You can do this by right-clicking on your cloud service and select "Create Test Storage Tables"
- When developing locally, the text field sizes are set at 1000 characters so you may need to manually increase this when you get strange exceptions
- You need to tick "Launch Browser" or else the web role will not start
- Sometimes you will need to shutdown and relaunch the Development Fabric when your Web Role starts to use a different port number from the one you have specified
What would be nice
It would be nice if it you could just auto-create code based on your existing SQL Database Tables in a similar way to how the LINQ DBML file is created. Otherwise, you will need to create an entity (Table Row) for each SQL Table that you have. An example of the persons Table in Azure Table Storage form can be viewed here.